-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remember buffer layout when resizing #11406
Labels
Comments
is this a graphical vim? If yes, can you check if |
ah, I think I misunderstood and this is a different problem. |
OK. I tried it anyway and it didn't change anything. |
**Describe the solution you'd like**
When a resize event occurs, all original buffer sizes should be
remembered. If a layout event does not occur before the next resize
event, then the original buffer sizes should be restored as possible.
That is, the middle buffer should get the extra space until it's as
big as it was, and then the bottom buffer gets the space.
This is actually quite difficult to make work in general.
For your specific situation, you could use the VimResized autocommand
event to resize windows in the way you like. There are some functions
to help with this, such as winlayout().
A more general problem is resizing Vim and positioning windows in the
best way possible. Taking into account windows with fixed sizes,
multiple tab pages, special buffers (help, quickfix), etc. It gets
complicated very quickly.
Simplest might be to store the current size (when the windows were last
split/closed/resized) and try to keep the same relative size. If done
right, then when making the Vim window smaller and then back to the
original, windows would be in the same place. However, when running
into windows with a fixed size or a minimal size it may not work
properly.
Perhaps someone would like to spend time on this, it will take some
trial and error to make it work well.
…--
Corn oil comes from corn and olive oil comes from olives, so where
does baby oil come from?
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request about something that is currently impossible or hard to do? Please describe the problem.
I have a 4k monitor attached to my laptop. The screen size is significantly larger on the 4k monitor, and so I sometimes like making my vim window tall to hold more buffers.
When moving the window to my smaller laptop screen, the OS shrinks the window to fit. When moving it back to the big screen, the OS restores the original size. The end result is that buffers at the bottom are shrunk to fit the new size. If the bottom buffer shrinks to one line, then it starts shrinking the second to bottom buffer. After this happens, and the original size is restored, the second to bottom buffer does not expand at all, all new space goes to the bottom buffer.
For my setup, when waking my laptop, for a small amount of time, all windows are displayed on my laptop screen, and then when the external screen wakes up, they are moved back to that screen. This temporary movement means that all my vim windows go through the shrink and grow steps, making all my buffers look squished in the middle.
Describe the solution you'd like
When a resize event occurs, all original buffer sizes should be remembered. If a layout event does not occur before the next resize event, then the original buffer sizes should be restored as possible. That is, the middle buffer should get the extra space until it's as big as it was, and then the bottom buffer gets the space.
Describe alternatives you've considered
I currently run
ctrl-w=
to equalize all buffers once waking my laptop.Additional context
This is how a 4-buffer window looks on my 4k screen:
This is how it looks once moved to my laptop screen:
This is how it looks once moved back to the 4k screen:
The text was updated successfully, but these errors were encountered: