Uh oh. I love non-native fullscreen mode. Unfortunately I don't have (and won't have) a Sierra beta to play around with.

Have the same issue

I can confirm this.

The text will appear for almost a second, then disappear behind the background (except for where the cursor is).

A keypress that scrolls the whole screen will temporarily bring the text back to where it should be, but then after a second it disappears again.

still happening on the 2nd gold master of macOS Sierra

Bump up for re-interest. This is really affecting my zen moment with MacVim 😄

We'll need to wait for Sierra to come out first so that the devs can work on it.

Well lucky for us, it gets released today!

Can confirm, this breaks for me as well :(

I can unfortunately also confirm this with the most recent official Sierra (10.12) in combination with the latest stable MacVim 8.0 (110).
Most of the screen is black, except for some areas and a red blinking cursor.
It also happens when I switch back to full screen. Switching to a normal window restores the normal rendering (yikes, that ugly window chrome though!)

🖐🏼 Same problem here! Any news on this issue?

This is a bit annoying, since native full screen mode does not return focus to terminal if you launch MacVim GUI from the command line and then ext (I diff files in MacVim GUI and do it in full screen to see files side by side).

Sorry to bug, any update on this? If I knew C or Objective-C I would totally try to help, but unfortunately I don't :(

Here is an observation that might help the devs with debugging.

If I recall correctly from long ago, non-native mode fullscreen involves painting the full screen with a color identical to that of the Vim background color, but underneath the "actual" MacVim window. (This is to make sure that there aren't borders left uncovered when the screen size isn't an exact multiple of the rows or columns.) All along, you may have seen this if you changed your colorscheme once already in NNFS, from a dark background scheme to a light one (or vice versa). If you made maxhorz or maxvert not be the full width or height, this was especially obvious. Changing the colorscheme to a sufficiently different one would leave the "borders" colored like the previous scheme's background. Going out of FS and back in would fix this.

Anyway, wrt this disappearing text problem on Sierra, you can see that it's this "fake" background painting that's covering the text and the "actual" MacVim window. E.g.: start MacVim, do "colo MacVim" and "set bg=light". Then go into NNFS. The text will disappear underneath the white "fake" background. While still in NNFS, do "set bg=dark". Wait a second, and text will disappear underneath the fake white again. Go out of NNFS and then go right back in. Now the text disappears underneath the (now) grey10 "fake" background.

I have no idea why this is happening on Sierra all of a sudden, but someone who knows what they're doing might now know where to start looking.

Just to add my voice to the, this is happening to me on macOS Sierra on a 2014 MacBook Air.

+1

+1

Hi folks - can we stop with the +1ing? There is a subscribe button directly to the right of this thread, for the purpose of being notified when there's work being done on this issue:

The +1s don't add to the discussion, and in many ways can be frustrating for both the developer and those who are only interested in following along with further work on this issue.

It seems like NSView backing layer(graphic context) will lose all rendering result when MacVim renders cursor.

set guicursor=a:blinkon0

Is that supposed to be a workaround, or just to demonstrate the nature of the bug? For me, that guicursor setting only stops the disappearing text until I move the cursor, at which point the text disappears again.

It does, however, reveal that if the cursor is on the last line in the window (not the buffer), it's only the text on lines above that one that disappear, while the cursor's line is entirely visible.

@nicksergeant I don't think people are +1'ing so they can subscribe. When there are 33 open issues on a project, isn't it nice to know which issues are affecting the most people?

Is there an alternate mechanism in github for people to use to indicate their interest in an issue getting sorted?

@trevvvy yup, you can add to the 👍 on the issue description itself:

Is there any way I can tip some money to get this fixed? It's really causing me productivity problems and would love to see it fixed asap.

Have anyone tried 10.12.2?

I gave up and switched to neovim :|

@splhack I'm using 10.12.1 and getting the same problem with fullscreen

@ralphholzmann it is fixed with neovim?

@splhack Having the same problem at 10.12.2 Beta (16C41b).

i've been poking at this bug over nights and weekends when I get a bit of time to spare. The bug, near as I can tell, has to do with CoreText and borderless windows. The bug still repros even if you short-circuit the full-screen behavior like so:

diff --git a/src/MacVim/MMWindowController.m b/src/MacVim/MMWindowController.m
index b6c6786..cf7be60 100644
--- a/src/MacVim/MMWindowController.m
+++ b/src/MacVim/MMWindowController.m
@@ -335,7 +335,7 @@
     if (fullScreenWindow) {
         // Delayed entering of full-screen happens here (a ":set fu" in a
         // GUIEnter auto command could cause this).
-        [fullScreenWindow enterFullScreen];
+        //[fullScreenWindow enterFullScreen];
         fullScreenEnabled = YES;
     } else if (delayEnterFullScreen) {
         // Set alpha to zero so that the decorated window doesn't pop up
@@ -743,7 +743,8 @@
         // custom full-screen can appear on any screen, as opposed to native
         // full-screen which always uses the main screen.)
         if (windowPresented) {
-            [fullScreenWindow enterFullScreen];
+            [decoratedWindow setStyleMask:NSBorderlessWindowMask];
+            //[fullScreenWindow enterFullScreen];
             fullScreenEnabled = YES;

             // The resize handle disappears so the vim view needs to update the

(repros even with a window smaller than the screen size)

The other thing I've noted is that what seems to happen is that each draw call is blowing away the previous window state: if you do :redraw!, the window is drawn properly at first, but then the next "partial" draw -- I think when the cursor starts to blink -- gets rid of all the window state before it that's drawn.

The MMFullScreenWindow.m implementation looks very "complicated", and maybe if we implemented it in a more simple fashion, it could do solve this issue.

can you guys test the master branch?

can you guys test the master branch?

It works great for me. Many thanks.

Thanks for the fix!

Unfortunately, it feels a bit laggy, especially when moving the caret around. It doesn't feel slow in the native full-screen mode though 🤔

So, I think I will be sticking in the native full-screen mode for now.

Awesome stuff @splhack 👏 ❤️

@amix praise must go to @osheroff :)

All praise @osheroff! 👏 ❤️ 💃

thx guys. @nuc yeah this is doing more computation than before (it currently draws offscreen and then copies the whole layer over), so drawRect is some milliseconds slower than with the previous method. There should be plenty of room to optimize it, but it'll need some work to draw to the layer offscreen and then update just the rects needed.

Thanks for your work on this @osheroff 👍 🥇 Is there any progress being made towards optimizing the draw lag or has that been abandoned?

Sadly, like @nuc stuck with using the native full-screen mode for now.