Oni can't display the contents of any file(including tutorials)

[rektrex]

Oni Version: 0.3.9
Neovim Version (Linux only): 0.3.2
Operating System: Arch Linux(Linux 4.20.0)

Issue: Oni can't display the contents of any file(including tutorials) or a new file. Tested with and without an existing init.vim, unmodified oni config, and no plugins.Other UI elements seem to work fine.

Screenshot after opening "Main.hs"

Expected behavior: The contents of the file is displayed.

Actual behavior: The editor pane is empty.

Steps to reproduce:

1. Open Oni.
2. Open a new file or an existing file or a tutorial lesson.

[oni-bot]

Hello and welcome to the Oni repository! Thanks for opening your first issue here. To help us out, please make sure to include as much detail as possible - including screenshots and logs, if possible.

[mbkv]

I'm new to the project, but I thought I'd take a look to see why. I cloned, built, and ran this project in debug mode to see if it'll give any better information. The only thing I found was an unhandled promise rejection in "TutorialManager"

TutorialManager.ts:135 Uncaught (in promise) TypeError: Cannot read property 'getLayerById' of undefined
    at TutorialManager.<anonymous> (TutorialManager.ts:135)
    at Generator.next (<anonymous>)
    at fulfilled (TutorialGameplayManager.ts:120)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188)

I can only assume there is a promise rejection elsewhere causing it to not open files, but this is the only place where it's unhandled. I spent a little bit of time looking around the project to try to better understand it

After following all of the function calls, I tracked it down to this line, which calls the getter activeBuffer, which gets the lastBufferId to retrieve the lastBufferId from the bufferManager. Only issue is, after a quick console.log, lastBufferId is null

It's getting a little bit late for me, I'll see if I can find out why this weekend.

[warptozero]

I'm getting the same blank editor behavior in oni 0.3.7 and 0.3.9. Rolling back neovim to 0.3.1 fixes the issue.

@rektrex on Arch you can do this with:

sudo pacman -U /var/cache/pacman/pkg/neovim-0.3.1-2-x86_64.pkg.tar.xz

[chuckmasucci]

Same for me running Manjaro and i3 on 0.3.9

[Honason]

I also can't see content, but only in tutorials. MacOS Mojave.

[gutuva]

Same for me: Linux 4.20.0-arch1-1-ARCH | oni 0.3.9-1 | neovim 0.3.3-1 | :(

[mbkv]

Looking at it a bit more. I think I found out a general gist of what's happening here. The issue is located on this line

oni/browser/src/neovim/NeovimInstance.ts

Line 476 in ed8d338

await this._checkAndFixIfBlocked()

On my machine, the function call doesn't seem to finish. Ironically the function name _checkAndFixIfBlocked is blocking the function from continuing. It seems like the request nvim_get_mode to neovim never completes and therefore oni never fully starts up. I'm not particularly sure why, or if this is even a bug upstream. What I know is that commenting that line makes it work

I listened on stderr and I listened on stdout. There's no output of any sort.

[ray-x]

I'm getting the same blank editor behaviour in oni 0.3.7 (also tried oni 0.3.9) and neovim 0.3.10 on ubuntu 18.10.

[delkano]

Following @mbitokhov findings, I've opened a bug in Neovim: neovim/neovim#9473

[justinmk]

#2613 is still pending. As explained there, Oni should call nvim_ui_attach after starting nvim --embed.

nvim_get_mode is (currently) "best effort", but inherently racy: if nvim_get_mode request is sent at just the "right" time then it could block. The best solution is to remove the need for nvim_get_mode , which is what #2613 should do.

In particular see #2613 (comment) and #2613 (comment) .

Simply remove the call to _checkAndFixIfBlocked entirely for Nvim 0.3.2.

[mbkv]

@justinmk

Thanks for your input! I don't know why that PR wasn't pulled in yet. But I'm glad there's some reasonable explanation of why nvim_get_mode was breaking

[akinsho]

@mbitokhov @rektrex, @CrossR is currently looking into this (I think) and reached a similar conclusion, sorry for the delay re. a response and a resolution, we're currently spending a lot of time working on Oni2 and the bits we need to get setup for that but this issue is a pretty big one we'd like to sort out

[CrossR]

Yeah, sorry for the delay, I've started a PhD recently so I've been more strapped for time.

The long story short of why the PR isn't merged is that currently, when simply removing the broken call, if neovim errors/gives any messages on startup (ie errors in your init.vim, loading a file with a swapfile around) Oni isn't able to react to this, due to the way the draw calls are setup.

As far as I can see, Oni will only start drawing once nvim is fully up and running, but when there is startup errors, the draw calls don't work (partially because the renderer isn't fully set up, partially because the renderer if it were setup, depends on a fully started nvim instance). The end result is that when there is errors/any startup messages, oni shows a blank screen for the editor, and only starts drawing once the user hits enter a bunch to agree to the messages they can't see.

It looks like I need to restructure the startup and how the drawing is done, so that the renderer is initialised earlier in the process, and that the drawing will work when nvim sends any startup put requests.

[mbkv]

@CrossR

Let me know if there's some way I can help. I don't know much about the nvim API. But I might be able to get something done on a weekend

edit: just for historical purposes. I just changed my username. formerly "mbitokhov"

[devendor]

This happens with several other GUIs on ubuntu bionic, nvim >=0.3.2.

In troubleshooting the same behavior in eovim, it looks like a blocking/empty vimenter request was changed or added in 0.3.2 to eliminate spurious UI events during initialization. I believe you are expected to send a command back after your initialization is complete, otherwise it's just a notice that UI events are being blocked waiting on your initialization to complete.

Below, is a representation of the offending message that eovim chokes on after running with an option to dump msgpack content.

--------
[0, 1, "vimenter", []]
--------
ERR<26988>:eovim /home/me/share/util/src/eovim/src/nvim.c:360 _nvim_received_data_cb() Invalid message identifier 0

I have full traces of working vs non-working neovim versions and more explanation over here:

jeanguyomarch/eovim#38

[CrossR]

I think I've got this working now, in that it will launch normally and will launch when there is any startup messages as well.

I'm still trying to work around setting the colour scheme up correctly (since I've had to move the first draw call around, the colour scheme isn't set so there is a split second flash of black before the theme kicks in).

@devendor , there is an explanation of this change over in NeoVims wiki : https://github.com/neovim/neovim/wiki/Following-HEAD#20180922 which might make things a bit clearer on why it was changed, why its a good thing and how to work around it.

[badosu]

Implemented the workaround on the oni AUR package:

sed -i -e 's/--embed/--embed","--headless/g' /opt/oni/resources/app/lib/browser/vendor.bundle.js

Thanks for the tip!

@rektrex @gutuva Consider upgrading

[badosu]

Let's use #2706 as the title is more descriptive of the underlying issue.