MacVim not computing window size correctly with multiple monitors (OS 10.10.3)

247 views
Skip to first unread message

Josh Petrie

unread,
Apr 15, 2015, 5:25:20 PM4/15/15
to vim...@googlegroups.com
Hi folks,
Recently I noticed MacVim was not starting with the proper window size. Specifically, even though I specify columns and rows in my .gvimrc (180x50), MacVim will launch with a window size of 57x23 every time. "verbose set co?" reports the column size is 180, "last set from ~/.gvimrc," even though the window is not that wide.

While trying to debug the problem, I launched MacVim via "mvim -u NONE -c "set columns=100" and noticed very curious behavior: repeatedly launching via this command-line would cause the window to appear sized to 100 columns, and then shrunk to a smaller size. I asked about this on StackExchange here: http://vi.stackexchange.com/questions/2915/why-is-macvim-starting-differently-every-other-invocation (which includes pictures, if that's helpful).

Both behaviors *only* seems to reproduce if I have a second monitor attached *and* if MacVim's last window was closed on the second monitor. If I watch closely, the window does appear to be showing up at the proper size and immediately getting resized down. I first noticed this behavior after upgrading to OS 10.10.3. I was, at the time, on an earlier snapshot of MacVim than 74 (I think), but I definitely am on 74 now. I can also reproduce the problem building MacVim from source.

Below is sort of a long-winded wall-of-text that details the steps I've taken so far to try and dig around in the debugger and see what's going on; I'm hoping that somebody can at maybe point me in a better direction (or confirm my theory); this is the first time I've poked around in MacVim's code specifically, and I might be going in circles.

When I enable the debug logging and launch MacVim "normally" (not via -u NONE etc), I see a call to gui_mch_set_shellsize like I expect:

...void gui_mch_set_shellsize(int, int, int, int, int, int, int)@1641: width=180 height=50...

followed by a few other messages, and then a note that

...Notify Vim that text dimensions changed from 180x50 to 57x23 (SetTextDimensionsMsgID)...

which appears to point to the issue. What I can't quite sort out is why MacVim thinks it should shrink the window. In both cases, during MMWindowController's windowControllerWillOpen method, MacVim adjusts the top-left point of the window frame via [win setFrameTopLeftPoint:topLeft]. In the buggy, dual-monitor case, this causes a windowDidResize event in MMWindowController which adjusts the frame size to contentSize, which is the default (small) value, which then causes MacVim to tell Vim to shrink (the "Notify Vim..." message above).

In the single-monitor case, setFrameTopLeftPoint does *not* cause the windowDidResize event.

In both cases, the window's frame is 480x382 before calling setFrameTopLeftPoint and the current top-left of the frame is different from the one about to be set by the call. In the dual-monitor case, however, the new window origin is on a different screen than the current origin.

My theory is that this switching between screens is sufficient to trigger the "resized" notification. I'm... not entirely sure what to do about this, since if I implement the windowWillResize delegate method, it doesn't seem to get called. It would be interesting to know if anybody can reproduce this behavior who is not yet on 10.10.3.

A really ugly band-aid is to check in windowControllerWillOpen if adjusting the top-left of the frame causes a screen switch, track that in the window controller, and check it when the window controller gets the resize callback. If the flag is set, early out as is currently done with the "setupDone" checks (clearing the flag first). This is, of course, gross. But it does seem to solve the issue; is there a more elegant way of doing an equivalent thing?

I'm going to dig around more and see if I can find any information on this 'resize when switching screens' notification behavior is new, or if not getting the 'will resize' callback is a bug.

Any thoughts from more experienced MacVim developers would be appreciated!

Thanks,
-- jmp

Josh Petrie

unread,
Apr 18, 2015, 8:14:19 PM4/18/15
to vim...@googlegroups.com
For what it's worth, I figured out what appears to be a much cleaner solution than I originally thought was necessary and created a PR for it at GitHub here: https://github.com/macvim-dev/macvim/pull/5

-- jmp
Reply all
Reply to author
Forward
0 new messages