Editor stops responding/displaying correctly on large external monitor

[laurenkt]

Apologies in advance for the difficulty I'm having reliably reproducing this. If you can give me any information on how to get more information from the app to help debugging I will happily do that.

I have recently started using Neovim.app on a large external monitor at a 90 degree rotation (so much taller than wide). This seems to be causing some issues with the app. Every so often when I focus the app it will cut off a large portion of the window (including any text in the file below a certain points, and the statusline and command line too) and then stop responding to commands or updating the view (there is a screenshot below to make this clearer).

If I click on my tabs it will change the title of the window to the correct tab, but the actual editor will not update to show the newly selected file.

This does not happen every time when focusing the window, but does happen regularly (at least once an hour).

Here's a screenshot of the display cut off (below). You can see the cursor floats in the middle of the screen (I can move the cursor around but it doesn't seem to correspond with what's on screen - I.e. I can position it in blank spaces where there is no text, but not in other areas where there is text).

Things I have tried

• Using full-screen mode or not full-screen mode (bug happens in both cases).
• Making the external display the primary display (bug still happens).

The only way I can get the app to start responding again after this happens is by dragging it back onto my primary display and moving it around a bit. Then it seems to update and come back to life. I am using three displays and dragging it onto the second does not make it come back, only when dragged onto the primary display.

[laurenkt]

One point of clarification: although I mention using a 3rd display in 90 degree rotation, I don't know if this is actually related any more than using any other external display - I've not used Neovim.app in an external display in any other configuration - so perhaps the issue is just with external displays in general. I'm not sure!

[rogual]

Are you using the latest release (brew install neovim-dot-app) or are you using the latest master (--HEAD)? There have been some fixes merges recently relating to large window support, so try master if you haven't.

On 4 Aug 2016, at 11:18, Lauren notifications@github.com wrote:

One point of clarification: although I mention using a 3rd display in 90 degree rotation, I don't know if this is actually related any more than using any other external display - I've not used Neovim.app in an external display in any other configuration - so perhaps the issue is just with external displays in general. I'm not sure!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[laurenkt]

Yes, I am currently using the latest master due to #281. Sorry, should have mentioned that. The issue is definitely present as of the latest commit in master.

[laurenkt]

I've noticed that when this happens there are a couple of errors logged in Console:

18/08/2016 14:25:07.090 Neovim[1180]: *** -[__NSCFConstantString stringByAppendingString:]: nil argument
18/08/2016 14:25:07.090 Neovim[1180]: (
    0   CoreFoundation                      0x00007fff99de94f2 __exceptionPreprocess + 178
    1   libobjc.A.dylib                     0x00007fff950bff7e objc_exception_throw + 48
    2   CoreFoundation                      0x00007fff99e504bd +[NSException raise:format:] + 205
    3   Foundation                          0x00007fff94d8dfc7 -[NSString stringByAppendingString:] + 96
    4   Neovim                              0x00000001079bec16 -[VimView(Redraw) doAction:withItem:] + 2134
    5   Neovim                              0x00000001079be31a -[VimView(Redraw) redraw:] + 634
    6   Neovim                              0x00000001079cd923 -[VimWindow notified:withData:] + 227
    7   Neovim                              0x00000001079d0b01 -[VimWindow handleEvent:] + 593
    8   Foundation                          0x00007fff94dd0fde __NSThreadPerformPerform + 279
    9   CoreFoundation                      0x00007fff99d7e881 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
    10  CoreFoundation                      0x00007fff99d5dfbc __CFRunLoopDoSources0 + 556
    11  CoreFoundation                      0x00007fff99d5d4df __CFRunLoopRun + 927
    12  CoreFoundation                      0x00007fff99d5ced8 CFRunLoopRunSpecific + 296
    13  HIToolbox                           0x00007fff95f7c935 RunCurrentEventLoopInMode + 235
    14  HIToolbox                           0x00007fff95f7c76f ReceiveNextEventCommon + 432
    15  HIToolbox                           0x00007fff95f7c5af _BlockUntilNextEventMatchingListInModeWithFilter + 71
    16  AppKit                              0x00007fff8e13adf6 _DPSNextEvent + 1067
    17  AppKit                              0x00007fff8e13a226 -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 454
    18  AppKit                              0x00007fff8e12ed80 -[NSApplication run] + 682
    19  Neovim                              0x00000001079b219a main + 186
    20  libdyld.dylib                       0x00007fff965c45ad start + 1

I'm assuming that must refer to this line.

Any ideas?

[laurenkt]

I've been trying to dig into this to find out why [NSString stringWithUTF8String:char_s.c_str()] returns nil.

At first I thought perhaps it was not getting a null-terminated string, despite c_str() meant to be null-terminated. However using initWithBytes:length:encoding: still occasionally returns nil so that can't be it.

Apparently these NSString methods return nil when the string is not a valid UTF8 string (or whatever encoding is specified). I'm not familiar with msgpack so I don't know if there's a reason it would be occasionally receiving a malformed UTF8 string. Are the strings definitely UTF8?

Alternatively perhaps there is an issue in the way Neovim.app is iterating through these strings index by index, perhaps it is breaking up unicode code points leaving invalid segments? I'm not a unicode expert by any means, but from reading the UTF-8 wiki page it seems like it should be possible to detect whether a character is part of a multi-byte sequence by checking the amount of most-significant 1's at the start of each byte. As std::string is not a UTF-8 implementation and can contain an invalid UTF-8 string then perhaps this is the most likely culprit.

I've no idea how all this relates to the conditions for which this bug presents itself to me: running Neovim in an external display. Perhaps the bug is happening either way but for some reason the window being on the main display seems to make it redraw correctly. I'll try leaving it running on my main display to see if the exception is thrown in the error console despite not being obvious in the interface.

[rogual]

Interesting stuff, thanks for your research!

Might be worth setting a conditional breakpoint to figure out what weird string we're getting.

[fsegouin]

Same issue here with an external thunderbolt display

[sophiedeziel]

I installed the last version, I also have that problem with a thunderbolt display, but only when the window's width is > 1550px (that number is not exact, ± 10px). Works perfectly fine on the retina display of my macbook pro.