Why does gVim resize and reposition itself after some actions?

Question

I started using gVim a few weeks ago. From early on, I noticed however some strange resizing of the complete gVim window when I perform certain actions. I think it is related to my use of Windows Aero Snap (on a Windows 7 x64 system).

Steps to reproduce (with an empty .vimrc file, and my vimfiles folder renamed):

1. I open gvim
2. I put my gvim window to the left side of my monitor with (a few taps on) win+left arrow
3. I create a new tab using :tabe

Result: gVim repositions itself somwehere else on the screen. So I have to reposition it using win+left arrow. Very annoying.

I have it with other tab and window actions as well, like: :vnew, C-W o, ...

Anybody any tips on why this is happening, and what i can do to fix it? I've already emptied my .vimrc file and temporarily renamed my ~/vimfiles folder to rule out the interference of any plugin.

Edit: Following Matthew's reply, and the info on :help bugs, I've send a bug report (this post actually) to [email protected]

Sarsaparilla

I can recreate this behaviour on my PC (also Windows 7 x64). Looks like a vim bug to me. – Islek

Do you use the original Vim 7.3 release? It's from 2010. A very recent installer can be downloaded from the Cream project; currently, it's at 7.3.709: sourceforge.net/projects/cream/files/Cream/0.01a – Redolent

@Ingo: yes, Vim 7.3.46. thanks for the link, but at current, no intent to switch to a 0.01 project. – Sarsaparilla

Sorry, that SourceForge link was old; here's a better one. The Cream project follows the Vim development very closely; it's the easiest way to get new Windows binaries without compiling yourself. sourceforge.net/projects/cream/files/Vim – Redolent

gvim can do this sort of thing in some situations if vertical scrollbars are being added or removed by your actions. Try ':set guioptions?', if it includes L or R, it may be your culprit. (Note that L is in the default settings.) Also you should definitely upgrade to a later build, there is certainly at least one bug in this area fixed since 7.3.46. The "Vim without Cream" install is well know to be reliable and kept quite up to date, and provides Vim without the Cream project addons. – Aman

@lessthanideal: indeed! It was set to the default "gmrLtT". Setting it to "gmrtT" (without the L) removes the resizing behavior. – Sarsaparilla

Oh good! I've provided an answer below, just repeating this with some more details :) – Aman

I would say that this is an artifact of how Vim attempts to do this: if it has control of the window, it tries to keep 'lines' and 'columns' the same. That just doesn't happen to be what you want in this case. – Droop

(Actually, if it's actively moving the window, that wouldn't be correct. That would be a bug. I haven't ever used Vim on Windows 7, so I don't know; but it doesn't happen on Ubuntu.) – Droop

The problem I encountered (with a dual-monitor system) moves the application window. Gory details here if you're interested.groups.google.com/forum/?fromgroups=#!searchin/vim_use/… As of build 7.3.638 (not quite the latest) this particular one hasn't been fixed. – Aman

Link in previous comment is @Aman (viz. broken); Correct link: groups.google.com/d/msg/vim_use/s2h1hmw6TZA/4BI29cl_LkgJ – Droop

An important update: removing the L from the guiptions fixes the behavior with windows (like when doing :vnew) but not with tabs. To fix the behavior with tab actions (like :tabe) I had to remove the e option (which just gives less fancy tabs). Upgrade to "vim without cream" 7.3.709 does NOT fixed both issues. – Sarsaparilla

Rabarberski, interesting - I do not have to remove e on my system. In fact the usual way I triggered the problem was to switch tabs or create new tabs, since that's one way to hide/show different windows with different scrollbars visible. I'll update the answer. @ChrisMorgan, cheers – Aman

Ugh. Still a problem in 8.0.2, as 2016 draws to an end... – Evansville

Answer 1

gvim can do this sort of thing in some situations with values of guioptions that make GUI controls such as scrollbars or tab page labels appear and disappear. Try the command :set guioptions?.

If the value displayed includes 'L' or 'R' (which optionally shows vertical scrollbars), it may be your culprit and you can remove the option as described below.

If it includes 'e', and especially if :set showtabline? shows that option = 1, that can also cause problems, and you could use the methods below to change either setting. (In this case the tab labels line only appears when there are at least two tabs.)

If it is neither of these, try and spot which parts of the GUI are appearing and disappearing when the problem occurs, and then find the option that controls that behaviour.

Example of how to fix if the problem value is 'L':

L is in the default settings, which are (from the help)

"egmrLtT"   (MS-Windows),
"aegimrLtT" (GTK, Motif and Athena).

You can therefore run one of these commands to fix it:

:set guioptions-=L  "just remove L
:set guioptions=egmrtT    "explicitly set the options you want, as noted you might want to remove 'e' as well

You can add one of these commands to your .vimrc file to always have it set.

---

You should definitely upgrade to a later build, there is certainly at least one bug in this area fixed since 7.3.46. That said, there are still problems as of 7.3.703.

The "Vim without Cream" install is well known to be reliable and kept quite up to date, and provides Vim without the Cream project addons. Future readers may find the bugs are fixed just by upgrading.

Aman

See the comment below my question about removing both the L option (for windows) and e option (for tabs) . – Sarsaparilla

Updated answer to account for this more general case. – Aman

Answer 2

A pull request was just merged in to Vim 8.0.1278. You can now add this following line to your config to alleviate the issue:

• guioptions+=k

What this does is avoid resizing the window when adding a vertical split, tab, etc. This makes the window size more consistent in general, but would also avoid triggering the resizing issue you mentioned when the Vim window is pinned to the left/right side.

If you don't want to use this new option, the issue is in how Vim resizes. In the Windows build, it uses the restored window's position (which is different from when it's pinned to right/left as it's kind of in a maximized mode), so whenever the code tries to resize Vim for whatever reason it will reset the position to the restored window position as well. There're further discussions here: https://github.com/vim/vim/issues/2180

Mehetabel