You are viewing an historical archive of past issues. Please report new issues to the appropriate project issue tracker on GitHub.

Bug #1493: Splits get moved when showing/hiding match list

Kind bug
Product Command-T
When Created , updated
Status closed
Reporter Greg Hurrell
Tags no tags

Description

To reproduce

  • open up a window with a few splits in it
  • bring up the Command-T match list
  • hit escape

Expected result

Splits should be exactly as before.

Actual result

Splits remain "pushed up" near the top of the window where VIM moved them to make room for the match window.

Other notes

You can achieve similar results when accepting a match from the match list.

Comments

  1. Greg Hurrell

    This is now mostly fixed as I am saving the window heights before showing the match window and restoring them afterwards.

    There is still an edge case or two, like the following, for example: 

    ----------------------------
               |
       1       |  
               |
---------------|      3
               |
       2       |
               |
----------------------------

               4

----------------------------

    When the match window is shown everything gets pushed up: 

    ----------------------------
---------------|      3
----------------------------
----------------------------
            matches     
----------------------------

    Afterwards, however, the reset sizes aren't quite right: 

    ----------------------------
       1       |
---------------|  
               |
               |      3
               |
       2       |
               |
----------------------------

               4

----------------------------

    In particular, note how window 1 is still scrunched up.

    What I think is happening is the following:

    • We ask VIM to restore window 1 to its original height but VIM refuses because window 3 (still collapsed) serves as a constraint
    • We ask VIM to restore window 2 and VIM again refuses
    • We ask VIM to restore window 3 and VIM agrees; it then needs to decide what to do with windows 1 and 2, so it decides to grow window 2 downwards, leaving window 1 squashed up

    Not entirely sure what the best way to handle this is.

    First idea that occurred to me is to do 1 pass through, then perform a second pass and re-request size changes for any windows that haven't acquired the desired size.

    The next idea that occurred to me is to sort the requests in order from tallest window through to shortest, so in the example above window 3 would get resized before 2 and 1.

    Will experiment.

  2. Greg Hurrell

    Looks like the second idea (tallest-to-shortest ordering) works.

    Marking as closed.

  3. Greg Hurrell

    Status changed:

    • From: new
    • To: closed
Add a comment

Comments are now closed for this issue.

Menu