Repository navigation
Window sizing issues #78
Description
Hi,
I use Divvy to place windows in different parts of the screen... this works mostly for MacVim but it's impossible to make the window full-screen height (even by dragging the bottom). It seems that the window manager won't let the window grow beyond full screen height, and this maximum height is slightly smaller than the actual screen (minus the menu bar).
Compare this to a native OSX window, which can grow well beyond the screen size if you move and drag, and will be placed flush to the corners of the screen in Divvy.
fwiw, this is slighly annoying but it's much much better than Adobe products, so this probably isn't easy.
Activity
chdiza commentedon Oct 1, 2015
This is due to the fact that, like with e.g. Terminal, MacVim deals with rows of a fixed height. It doesn't make sense to display a fraction of a row, so if the screen height isn't a multiple of the row height, there will be a bit of space left over. There is no reason to fill it, since Macvim can't put a row there.
A MacVim window will easily grow beyond the screen size if you move-and-drag. It won't do this in the vertical direction, of course, but neither will "a native OSX window".
If by "move and drag" you mean some operation in Divvy, then this is the wrong forum.
andrewplummer commentedon Oct 1, 2015
If this is some kind of technical limitation, then I can get it, but there are plenty of other apps that deal with "fixed height" (basically any other text editor... Sublime Text, etc?) that don't have this issue.
Sure it will. Take a finder window and drag it down to the bottom of the screen, then vertically resize up. You can keep doing that to make it as tall as you like. That being said, it sounds like the "fixed height" thing is the actual issue, so I guess this part isn't too relevant.
chdiza commentedon Oct 1, 2015
I didn't know a window could be resized from the titlebar. Shows how often I resize by hand!
I'm pretty sure this is a technical limitation that's been addressed more than once (here or the mailing list, I can't recall). But on top of that, I'm not really sure what one would want Vim to be "putting" there in that thin little space. Certainly not a row, under the cmdline. Then what? A colored strip matching the background color? That would look weird, because it would make the value of
cmdheightappear bigger than it really is. A strip of a different color? That looks worse than leaving it unoccupied.Unlike those other editors (AFAIK), Vim cannot display vertical fractions of a row of text. It scrolls only in whole rows.
andrewplummer commentedon Oct 2, 2015
OHHHH I get it now! I just tried this out with VimR and and GVim on Ubuntu and they both have the same issue. It's because vim naively (don't mean anything by this...of course I realize it was never intended as a windowed app) puts the statusline and everything else below N rows. Also I jack up my font size pretty high so the effect is more pronounced.
If my opinion is worth a damn at all (which it's probably not), I would be delighted if it put a strip that matches the background color at the top, just below the titlebar. That way the window would sit flush but the statusline would still be at the bottom. Of course an option to put it at the very bottom of the window (or not use at all) would be even better.
But feel free to ignore this. Now that I get how it works the whole thing sits better... plus I can just turn down the font size.
kaiwood commentedon Oct 2, 2015
There are 2 settings, MMTextInsetTop and MMTextInsetBottom, to slightly adjust the window size. What it does is, it adds additional pixel rows on the top and the bottom of the window. For example, I've set mine to:
Now when I maximize the window, it aligns pixel perfect with the dock.
It really depends on the screen size, height of the dock and your font, so you would have to find your own "best settings" for your machine. A word of caution: If you set any of this too high, Vim will not be able to render the last row of text and the window will get exactly one font row smaller then before, so you might want to increment one pixel-row at a time.
Oh, and keep in mind that you have to restart MacVim each time you change these ;)
andrewplummer commentedon Oct 2, 2015
HOLY BAT DROPPINGS ... you did it!
That's exactly what I was looking for!
andrewplummer commentedon Oct 2, 2015
So I'll just leave this issue for you to close, but this completely solves the issue for me!
andrewplummer commentedon Oct 2, 2015
So this fix is so almost perfect I feel bad for commenting, but just to be thorough: I tweaked these values (and also
MMTextInsetRight) to get it perfect when I'm using Divvy and putting in on half the screen. But when I'm not using an external monitor I put MacVim in full screen (divvy "full", not OSX native fullscreen) because of the small screen. Presumably the gutter is double what I made it for "half" the screen because there's still a gap, but since it's a static value there will always be a gap I suppose.Seriously though............. not complaining........
andrewplummer commentedon Jan 12, 2016
Interesting note, I just got a "tip" popup from iTerm 2 which said "Hold ^ while resizing the window to not snap to characters" (ie. resize by pixel). Tried it out and sure enough it works, so it seems like they are handling this quite well. iTerm works great with Divvy as well, it simply adds some padding around the edges.
ychin commentedon Sep 11, 2022
This was closed a while ago, but just to tag this as a duplicate of #948, which is going to be closed by #1276.