You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
One of the recent fullscreen commits broke non-native Fullscreen mode #488
changed the title [-]One of the two fullscreen commits broke MacVim non-native Fullscreen[/-][+]One of the recent fullscreen commits broke non-native Fullscreen mode[/+]on Apr 1, 2017
The recent slew of commits to fix fullscreen artifacts has, unintentionally, broken non-native fullscreen mode ("NNFS").
If I enter NNFS and then press the key combo to reduce the font size, what should happen is that the font size shrinks but that MacVim compensates for this by increasing the number of &colums shown on the screen. This is how it always worked in NNFS.
But beginning with 3fb41cc, the actually observed behavior is that (a) there is no such compensation, and (b) MacVim sort of hangs: the cursor won't blink, I can't do :redraw to erase the artifacts, etc.
I'm not a Cocoa programmer, so I can't help with fixing the code. Perhaps some of the changes were supposed to have been for native-fullscreen mode only and not NNFS. Please fix or revert these recent changes.
Another strange side-effect: after going into NNFS and then enlarging the font size, the Vim status bar disappears "below" the bottom edge of my monitor, and returns about one second later. That never used to happen either.
The failure to expand the &columns does happen there. I had forgot that I was carrying a patch to revert the disastrous #103 (see my report in #127, which nobody has done anything about).
Thing is, though, when carrying that patch but before the last few commits, MacVim would behave in the expected way mentioned above. After the last few commits, it seems to not matter whether or not I carry the patch that reverts #103; I get the bogus behavior described above.
(In other words, the only way I can get the expected and proper behavior is to (a) rollback the last couple of commits, and (b) revert #103.)
(In still other words, the last few commits have broken my fix for #127.)
Also, the strange "statusbar disappears for one second" thing is not present in 8.0-129; it's brand new to the last few commits. My guess is that it has to do with that 1 second safety delay you put in.
I'm curious why these changes were made to apply to both of the two fullscreen modes. There weren't any artifacts when moving in or out of NNFS. The only artifacts for NNFS were #127 and other small nits that have to do with changing font size, not transit to or from NNFS.
I was trying to fix a general rendering bug. It's unfortunate that it also broke your workaround to #127 (and for what it's worth, I did observe artifacts when moving into/out of NNFS), but making it only apply to certain modes would have been incorrect, and more complicated.
See my last comment on #127 — I think I found the issue, and hopefully that change can replace your workaround :).
I was curious because although it's more complicated to treat NNFS and NFS differently, it seems to be sometimes required. For example, NFS has to contend with "Split Screen", while NNFS does not. IIUC, the cause of #127 is that #103 applied a fix for Split Screen to both fullscreen modes, when it should've only messed with NFS.
Anyway, whether that's right or not, I sure do appreciate you taking a look at this, because as far as I'm concerned NNFS is pretty much the only reason to use MacVim rather than just good ol' console Vim. NNFS has been around since 2008 and I think I can't live without it.
BTW, the only artifacts I see during the transition to or from NNFS have been there since 2008, which is why they don't even register to me anymore. (I presume you're talking about an incredibly brief white rectangle covering part of the newly-not-full-screen-anymore Vim window.)
I'm not sure if this is related, but I just updated to the latest version (not sure which one I was before, but generally I accept all automatic updates) and fullscreen is broken for me. I really don't understand why this changed. Seemed perfect before.
What happens is that when I enter fullscreen, the max window height is preserved. Since out of full screen MacVim has the menu bar, the height is smaller than the full screen possibility. So I'd see black bars on top and bottom of the screen. This still happens. However: previously I'd hit ⌃⌘Z and it would fix itself. Yes, sometimes the white rectangle appears briefly but soon disappear, or disappear when creating a split.
Now, zoom does nothing. I see the status bar moving but then goes back in a flash. And I'm left with black bars on top and bottom of the screen.
Activity
[-]One of the two fullscreen commits broke MacVim non-native Fullscreen[/-][+]One of the recent fullscreen commits broke non-native Fullscreen mode[/+]chdiza commentedon Apr 1, 2017
The recent slew of commits to fix fullscreen artifacts has, unintentionally, broken non-native fullscreen mode ("NNFS").
If I enter NNFS and then press the key combo to reduce the font size, what should happen is that the font size shrinks but that MacVim compensates for this by increasing the number of
&columsshown on the screen. This is how it always worked in NNFS.But beginning with 3fb41cc, the actually observed behavior is that (a) there is no such compensation, and (b) MacVim sort of hangs: the cursor won't blink, I can't do
:redrawto erase the artifacts, etc.I'm not a Cocoa programmer, so I can't help with fixing the code. Perhaps some of the changes were supposed to have been for native-fullscreen mode only and not NNFS. Please fix or revert these recent changes.
s4y commentedon Apr 1, 2017
Oof. Looking into this now.
chdiza commentedon Apr 1, 2017
Another strange side-effect: after going into NNFS and then enlarging the font size, the Vim status bar disappears "below" the bottom edge of my monitor, and returns about one second later. That never used to happen either.
chdiza commentedon Apr 1, 2017
(That last thing I mentioned happens around half of the time.)
s4y commentedon Apr 1, 2017
Still looking into it, but it doesn't seem to be related to that commit. The same thing happens to me in 8.0-129. Could you confirm that?
s4y commentedon Apr 1, 2017
Could this be #127?
chdiza commentedon Apr 1, 2017
The failure to expand the
&columnsdoes happen there. I had forgot that I was carrying a patch to revert the disastrous #103 (see my report in #127, which nobody has done anything about).Thing is, though, when carrying that patch but before the last few commits, MacVim would behave in the expected way mentioned above. After the last few commits, it seems to not matter whether or not I carry the patch that reverts #103; I get the bogus behavior described above.
(In other words, the only way I can get the expected and proper behavior is to (a) rollback the last couple of commits, and (b) revert #103.)
(In still other words, the last few commits have broken my fix for #127.)
Also, the strange "statusbar disappears for one second" thing is not present in 8.0-129; it's brand new to the last few commits. My guess is that it has to do with that 1 second safety delay you put in.
chdiza commentedon Apr 1, 2017
Also, #405 introduced a bunch of strange artifacts when adjusting the font size when already in NNFS, but they seem unrelated to the present problem.
chdiza commentedon Apr 1, 2017
I'm curious why these changes were made to apply to both of the two fullscreen modes. There weren't any artifacts when moving in or out of NNFS. The only artifacts for NNFS were #127 and other small nits that have to do with changing font size, not transit to or from NNFS.
s4y commentedon Apr 1, 2017
I was trying to fix a general rendering bug. It's unfortunate that it also broke your workaround to #127 (and for what it's worth, I did observe artifacts when moving into/out of NNFS), but making it only apply to certain modes would have been incorrect, and more complicated.
See my last comment on #127 — I think I found the issue, and hopefully that change can replace your workaround :).
chdiza commentedon Apr 2, 2017
I was curious because although it's more complicated to treat NNFS and NFS differently, it seems to be sometimes required. For example, NFS has to contend with "Split Screen", while NNFS does not. IIUC, the cause of #127 is that #103 applied a fix for Split Screen to both fullscreen modes, when it should've only messed with NFS.
Anyway, whether that's right or not, I sure do appreciate you taking a look at this, because as far as I'm concerned NNFS is pretty much the only reason to use MacVim rather than just good ol' console Vim. NNFS has been around since 2008 and I think I can't live without it.
BTW, the only artifacts I see during the transition to or from NNFS have been there since 2008, which is why they don't even register to me anymore. (I presume you're talking about an incredibly brief white rectangle covering part of the newly-not-full-screen-anymore Vim window.)
sidyll commentedon Apr 19, 2017
I'm not sure if this is related, but I just updated to the latest version (not sure which one I was before, but generally I accept all automatic updates) and fullscreen is broken for me. I really don't understand why this changed. Seemed perfect before.
What happens is that when I enter fullscreen, the max window height is preserved. Since out of full screen MacVim has the menu bar, the height is smaller than the full screen possibility. So I'd see black bars on top and bottom of the screen. This still happens. However: previously I'd hit ⌃⌘Z and it would fix itself. Yes, sometimes the white rectangle appears briefly but soon disappear, or disappear when creating a split.
Now, zoom does nothing. I see the status bar moving but then goes back in a flash. And I'm left with black bars on top and bottom of the screen.
s4y commentedon Apr 19, 2017
@sidyll: I haven't been able to reproduce this. Here's what it looks like for me:
Could you provide some more detailed instructions on how to make this happen, and a screenshot or screen recording if possible?
It might be worth making a fresh bug, too.
s4y commentedon Apr 19, 2017
P.S. @chdiza, do you want to close this bug? I think everything's fixed, but let me know what's left if not.
sidyll commentedon Apr 19, 2017
Thank you @s4y, I will post as another bug with more information.
chdiza commentedon Apr 20, 2017
I'll close, because the remaining problem (incorrectly sized window on exiting NNFS) is best reported in another bug.