13

I noticed when I sat down to do some work on my MacBook today that at some point recently something had gotten screwed up with respect to my .gvimrc settings: when I launched MacVim, everything seemed normal except that my window was very small (approximately the default size). Curious, I tried verbose set columns? which told me "180, last set from ~/.gvimrc" even though the window was obviously not 180 columns wide. set columns=180 restored the window to the expected width.

After the usual debugging and bisection of my RC files, I noticed something unusual. I'm not sure if this is related to my column sizes not applying or not, either way it's curious and I can't figure it out.

If I run: mvim -u NONE -c "set columns=100", I get a window like this: mvim 1

If I run exactly the same command again, I get this: mvim 2

verbose set co? reports 100 and 66, respectively, in both cases saying "last set from -c argument." Repeating the launch command causes the window state to alternate.

I've tried nuking .viminfo between runs; it has no effect.

I'm using MacVim snapshot 74 now, although I was on an earlier version when this started happening and upgraded to see if it was just a versioning thing. I'm on 10.10.3, and it's possible that this behavior is due to a MacVim-specific bug that has surfaced as a result of the OS update (which only happened recently). However if I install MacVim on my wife's laptop (running the same OS version) the behavior does not reproduce.

I'm at a loss. What on earth could be causing this behavior?

EDIT: After continued debugging, I've noticed it seems to only reproduce this way if I have an external monitor connected to the laptop. This leads me to believe it's some kind of bug.

Improve this question

1 Answer 1

Reset to default
16

After spelunking the MacVim code base for a few hours, I think I can see why this happens.

When MacVim starts, it reads the previously-saved window position from NSUserDefaults and tries to restore that position. At the point the window hasn't actually been shown yet, and it's origin is some (possibly OS selected) default that is always on the 'main' screen. If the previous position of the window was on a different monitor, changing the window's position will trigger a "resized" event (it's possible this is new, or a bug, in 10.10.3, since a corresponding "will resize" event is not generated).

This will cause MacVim to try to resize the Vim backend, but it's too early in the execution of the process for the state which is used to effect that resize to be properly constructed. Thus, MacVim requests that Vim resize itself to what is effectively a default value, which causes the window to shrink the next time MacVim gets a response to the resize from the Vim backend (MacVim resizes windows lazily).

EDIT: This change fixes the bug, I think. It causes window resizes not to propagate down into the Vim backend until the window has been presented.

Improve this answer
2
  • 1
    The link is broken, which is a shame because it sounds interesting. (Also: I love your use of the word "spelunking.") :D
    – Wildcard
    Commented Mar 19, 2016 at 8:42
  • @Wildcard I updated the link to point at the PR I eventually made instead of the commit in my local branch (which I deleted when I got commit access to MacVim's main repository).
    – user72
    Commented Mar 19, 2016 at 14:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.