size of hidden bottom scrollbar is not reclaimed in window size calculations

[masukomi]

Describe the bug
When the bottom scrollbar is toggled off. It is not possible to make a window that is as tall as the available screen real estate. You can't drag (expand) the bottom edge of the window to the bottom of the screen. If you drag the whole window down such that the bottom edge is aligned with the bottom of the screen you can't drag the top edge to expand to meet the top of the screen. The same applies to corners. It appears as if MacVim is still counting the pixels required for the scrollbar that has been hidden.

To Reproduce
Toggle the visibility of the bottom scrollbar such that it does not appear. Attempt to drag the window to meet the bottom edge of the screen. Alternately, use a window manager or anything else that can resize windows (Moom, Amethyst, etc)

Expected behavior
The window should be expandable to the full height of the screen (not counting the macOS Menu bar)

Screenshots

Environment (please complete the following information):

MacVim about says: Custom Version 8.1.1722 (157)
macOS: 10.14.6 (18G95)

[eirnym]

@masukomi Thank you for an issue

The size of gap is less than one symbol. MacVim tries to extend on sizes to make sure last line will be shown fully without cutting it in the middle. May be it'll change in the future.

some issues you can read about the similar requests: #273 #271 and some other you can find around.

[ychin]

As @eirnym said this is as designed and how GVim works. We snap the window size to the fixed intervals of the column/row size. Only time we don't do this is when the window is in fullscreen mode.

However, I do find it a little annoying. I'm considering making window size smoothly transition instead of snap to fixed interval, maybe only if set guioptions+=k is on, so I'm leaving this issue open.

[masukomi]

However, I do find it a little annoying.

I use window management tools like Moom and Amethyst. When you invoke commands that are supposed to resize things and they work fine everywhere else and only mostly work here you really start scratching your head going "wtf is going on?!"

I get why it behaves the way it does, and appreciate the explanation @eirnym . From a user perspective it's just really.... weird and inconsistent.

[ychin]

I use window management tools like Moom and Amethyst. When you invoke commands that are supposed to resize things and they work fine everywhere else and only mostly work here you really start scratching your head going "wtf is going on?!"

That's because MacVim tells the window manager it only wants to snap to integral multiples of text size:

[decoratedWindow setContentResizeIncrements:cellSize];

You can actually remove that constraint in the code now and it would mostly work but there's still some rendering artifacts still as the draw invalidation code is a little buggy and there's another PR (#858) that may make it better. I will probably expose an option to allow smooth resizing (which will allow you to resize the window to any size) after we have fixed up the bugs (right now MacVim would occasionally clear the window when you are resizing which is annoying).

[9mm]

@ychin that would be amazing. Do you know if that's still the plan? FWIW VimR does a really good job of this (handling the smooth resizing while still having vim interface 'snap' to the text line height). It basically creates <= 1 line of black space above the status bar, and when it gets > 1 it adds another line and goes back to <= 1 line of black space.

[ychin]

It's been a while, but #1276 will now implement this feature. One thing I didn't like from other Vim GUIs like VimR and Neovide was the graphical glitches and jumpiness that happens when you live resize the window, but they are all addressed in that PR now as the CoreText renderer would extend the last column a little to the right to make it fill all the way so make it feel more stable as you resize the window.

Another PR (edit: #1280) will also make it possible to pin the cmdline to the bottom of the window because with live resizing the window size is often not directly the size of the Vim's content.

Contemplating making this the default, but will probably sleep on it a little bit first to gather feedbacks.