Add GUI option 's' to prevent resizing when tab bar is shown, vert split happens,etc #703

ychin · 2016-03-21T06:52:29Z

Currently, in Vim's GUI, if you do things like adding a new tab (which triggers the tab bar to show under default setting of "showtabline = 1"), or adding a vertical split which creates another scrollbar, the whole GUI resizes. This is because it's trying to preserve number of 'lines' and 'columns'. The only time it doesn't do that is when the window is maximized, since the GUI is fixed in place and resizable. Vim does the sensible thing and reduce or increase lines and columns to fit the UI.

I think this is a pretty annoying part of using Vim's GUI, as most modern editors never resizes itself even when you add or remove GUI elements. The editing pane just shrink to fit the UI. Also this mode currently breaks Window's aero snap left/right mode (by either pressing +/ or dragging the window to left or right edge of the desktop). This is because that mode isn't classified as "maximized" by the window manager, and Vim then tries to change its own size when adding tab bar etc.

I added a GUI option 's' to fix this behavior while maintaining backward compatibility for people who really likes how Vim preserves their fixed 60 lines and 80 columns no matter what. :)

See also:

Most recommendations just involved asking users to turn off scrollbars or turning them on permanently which seems like a subpar solution.

cvwillegen · 2016-03-21T09:19:43Z

runtime/doc/options.txt

+		'lines' and 'columns' when showing tab page labels,
+		adding/removing scrollbars, etc.  Instead, the behavior is
+		similar to when the window is maximized and will adjust
+		'lines' and 'columns' to fit withint the GUI.


within (typo in the doc)

Thanks. Pushed a new commit.

On 2016-03-21, cvwillegen wrote:

In runtime/doc/options.txt:

@@ -3824,6 +3824,13 @@ A jump table for the options with a short description can be found at |Q_op|.
removing it after the GUI has started has no effect.
'go-F'
'F' Add a footer. Only for Motif. See |gui-footer|.

_'go-s'_

's' Fix GUI from resizing automatically. If set, this will

prevent the GUI from resizing itself to fit the same number of

'lines' and 'columns' when showing tab page labels,

adding/removing scrollbars, etc. Instead, the behavior is

similar to when the window is maximized and will adjust

'lines' and 'columns' to fit withint the GUI.

This isn't a fix, it's a user preference. I think "Fix" should be
changed to "Prevent".

Regards,
Gary

Sure, I really meant "fix" as in fixing in one place (since this fixes the size and prevent it from changing), rather than fixing a problem. Updated commit to have the more precise wording per your suggestion.

…els, vertical scrollbars, etc are added.

ychin · 2016-03-21T10:17:03Z

Pushed new commit to fix the "within" typo.

nuko8 · 2016-03-21T11:57:51Z

Is it possible to rewrite the patch in such a way that only those who prefer to the proposed behavior are supposed to modify their .vimrcs?

Everybody knows and expects Vim behaves as such it does now, and some people are satisfied with it.

If your patch is merged, Vim fails their expectation, and those who satisfied with the current behavior are forced to modify their .vimrcs to get Vim to revert to the current behavior.

Naturally, it is those who prefer to the proposed behavior who should/must modify their .vimrcs.

IMHO, it would be better to make the patch true backward-compatible.

ychin · 2016-03-21T12:29:34Z

@nuko8 It does work the way you described? I guess I wasn't clear in my comment, but you have to manually set guioptions+=s in order to get the new behavior, hence my comment about backward compat.

The change in gui.c will only be true (hence leading to the fixed GUI path) if the option is set.

nuko8 · 2016-03-21T15:29:53Z

you have to manually set guioptions+=s in order to get the new behavior

I wish I had this clarification in your first comment.

The change in gui.c will only be true (hence leading to the fixed GUI path) if the option is set.

But to make this assertion hold true, the patch also changes the value of the first argument of gui_set_shellsize() from FALSE to TRUE at some places. These changes don't revert to the original value when the option is unset. I feel uneasy about that and wonder if backward-compatibility is indeed maintained.

ychin · 2016-03-21T19:56:48Z

@nuko8 Yes, sorry I should have been clearer about the change.

The places where I changed gui_set_shellsize(FALSE,...) to gui_set_shellsize(TRUE,...) actually prevents this option from kicking in. The new GO_FIXWINDOWSIZE option only kicks in when FALSE is passed in. Otherwise it always tries to set resize the GUI windows. The reason I had to make those changes in the 3 lines was that those were the places where the GUI was being initialized. If I don't make that change, and the user has the new set guioptions+=s in the vimrc, then the GUI will initialize in a tiny window since it never got the chance to resize itself to a reasonable size. We need the first initialization to set the window size properly before having this GUI option kicks in in the future.

Do note that changing to gui_set_shellsize(TRUE,...) does have the issue that if the window is already maximized, then it will still resize it and potentially unmaximizing the window. That said I have not found any place in Vim where the GUI actually has the capability to start and initialize in maximized state. In Windows the way to do it is by passing a simalt ~x command (which happens after initialization and actually a hack by going through the GUI's right click menu), and in GTK it doesn't seem possible, so this shouldn't be a problem. If it is I think we can add another parameter to gui_set_shellsize() to indicate the difference between maximized and guioptions+=s but I felt that it would complicate the code so didn't do it that way. (It would look something like gui_set_shellsize(int mustset, int fit_to_display, int direction, int ignore_go_fixedwin))

Edit: Long story short. I don't believe the behavior should change at all for users if they don't use the new GUI option. This is unless Vim can start and init maximized right off the bat but I don't believe that is the case anywhere.

Edit 2: Ah ok re-reading your comment I understand your objection. You are suggesting that I should pass in TRUE only if the option is set (otherwise leave it at FALSE). I'm a little hesitant because if setting to TRUE leads to a bug (i.e. if we initialize GUI with a maximized window) it will still manifest itself, but only if guioptions+=c. Seems better to make sure the unified code path doesn't have any issues in it. As I said those TRUE's shouldn't matter if the option isn't set because they are AND'ed together with (vim_strchr(p_go, GO_FIXWINSIZE) inside the function. I can still make the change though if it makes the reviewers happy.

ychin · 2016-04-04T02:58:52Z

Hi, since I don't see more comments but the PR is still open, just want to ask if there's anything I need to do to make this a viable pull request?

As I mentioned the behavior should be the same for any users who don't modify their vimrc's. I made sure to check how the initialization and maximize behaviors work under GTK and Windows (since these are really the only two configs affected by this change) and they behave the same as before with a normal vimrc (without the new guioption).

I also fixed up all the documentation wording as suggested by reviewers. Any thoughts would be appreciated.

brammool · 2016-04-04T20:03:30Z

ychin wrote:

Hi, since I don't see more comments but the PR is still open, just
want to ask if there's anything I need to do to make this a viable
pull request?

As I mentioned the behavior should be the same for any users who don't
modify their vimrc's. I made sure to check how the initialization and
maximize behaviors work under GTK and Windows (since these are really
the only two configs affected by this change) and they behave the same
as before with a normal vimrc (without the new guioption).

I also fixed up all the documentation wording per suggested by others.
Any thoughts would be appreciated.

I usually wait a little while until I hear from others. I have a large
pile of things to look at, but I'll get to it eventually.

Your fault: core dumped

floyd-may · 2017-06-02T16:05:10Z

The proposed behavior (reachable by set guioptions+=s) makes sense to me. I hit Google looking for answers to this strange behavior when I had gvim docked to one side and then opened a new tab only to discover that my gvim moved and resized itself. Very much unexpected behavior.

In the meantime, are there any workarounds?

ychin · 2017-06-02T20:06:26Z

Author of the patch here. I think the standard recommendations are to keep the tab bar, statusline, and scrollbar visible at all times, which will prevent the window size from jumping. You will still get an issue when doing a vertical split since it will show an additional scrollbar (unless your setting is to not show scrollbars at all time).

Otherwise you can either rally to have this patch integrated or make a local fork with my patch and build it yourself so you can use this new option.

brammool · 2017-11-09T17:37:33Z

Note: I decided to use "k" for "Keep the size" instead of "s" which I can't associate with what it does.

ychin · 2017-11-09T17:39:16Z

The "s" just stood for "size", but "k" sounds good!

Problem: GUI window always resizes when adding/removing a scrollbar, toolbar, etc. Solution: Add the 'k' flag in 'guioptions' to keep the GUI window size and change the number of lines/columns instead. (Ychin, closes vim#703)

Problem: GUI window always resizes when adding/removing a scrollbar, toolbar, etc. Solution: Add the 'k' flag in 'guioptions' to keep the GUI window size and change the number of lines/columns instead. (Ychin, closes vim/vim#703) vim/vim@8ac4415

Starting from Windows 7, MS-Windows supports Aero Snap (and it is now called just Snap). It can snap windows on the edges of the screen. If a gVim window is snapped, and then the window size is changed by a command like `:vsp` or `:tabe`, snapping will be cancelled. This might be annoying for some people. Actually this can be avoided by setting `:set go+=k`, but this also changes the behavior when the window is not snapped. This patch detects if the gVim window is snapped, and acts like if the window is maximized. So, if the window is snapped, and even if a command like `:vsp` is executed, snapping will be kept. But if the window size is explicitly specified (e.g. `:set lines=30`), the size will be changed. Related: vim#123, vim#703, vim#2180

• vim/vim#703 • macvim-dev/macvim#1006

cvwillegen reviewed Mar 21, 2016
View reviewed changes

Add GUI option 's' to prevent resizing when GUI elements like tab lab…

79e2a60

…els, vertical scrollbars, etc are added.

ychin force-pushed the master branch from 628b557 to 79e2a60 Compare March 21, 2016 10:15

Update Options.txt for better wording of gui options

8c3233e

Merge remote-tracking branch 'vim/master'

bab281c

chrisbra mentioned this pull request Oct 1, 2017

Erroneous resizing and re-positioning when splitting pane vertically #2180

Closed

k-takata mentioned this pull request Oct 3, 2017

GVimのスナップ状態が解除されることがある vim-jp/issues#1078

Closed

k-takata mentioned this pull request Oct 13, 2017

Windows gui: window position is changed when invoking :vert & :tab under certain conditions #123

Closed

brammool closed this in 8ac4415 Nov 9, 2017

ychin mentioned this pull request Dec 19, 2017

Support guioption 'k' to avoid resizing window when adding tabs/vsplits/etc macvim-dev/macvim#617

Closed

ychin mentioned this pull request Dec 26, 2018

Fixed gvim --windowid feature bug in Windows #3616

Closed

ychin mentioned this pull request Feb 6, 2019

gVim on Windows starts with a tiny window when using "set guioptions+=k" #3808

Closed

k-takata mentioned this pull request Jul 17, 2020

win32: Support snapping on the edges of the screen #6467

Closed

serban added a commit to serban/dotfiles that referenced this pull request Mar 7, 2022

vimrc: Keep window size when changing scrollbars

e9a8970

• vim/vim#703 • macvim-dev/macvim#1006

Uh oh!

Add GUI option 's' to prevent resizing when tab bar is shown, vert split happens,etc #703

Add GUI option 's' to prevent resizing when tab bar is shown, vert split happens,etc #703

Uh oh!

Conversation

ychin commented Mar 21, 2016

Uh oh!

cvwillegen Mar 21, 2016

Choose a reason for hiding this comment

Uh oh!

ychin Mar 21, 2016

Choose a reason for hiding this comment

Uh oh!

vim-ml Mar 21, 2016

Choose a reason for hiding this comment

Uh oh!

ychin Mar 21, 2016

Choose a reason for hiding this comment

Uh oh!

ychin commented Mar 21, 2016

Uh oh!

nuko8 commented Mar 21, 2016

Uh oh!

ychin commented Mar 21, 2016

Uh oh!

nuko8 commented Mar 21, 2016

Uh oh!

ychin commented Mar 21, 2016

Uh oh!

ychin commented Apr 4, 2016

Uh oh!

brammool commented Apr 4, 2016

Uh oh!

floyd-may commented Jun 2, 2017

Uh oh!

ychin commented Jun 2, 2017

Uh oh!

brammool commented Nov 9, 2017

Uh oh!

ychin commented Nov 9, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants