New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Latest unstable version of Neovim installed via Ubuntu PPA repository has blanked editor window #2580

Open
PaleAugust opened this Issue Sep 24, 2018 · 9 comments

Comments

Projects
None yet
3 participants
@PaleAugust

PaleAugust commented Sep 24, 2018

Oni Version: 0.3.6
Neovim Version (Linux only): v0.3.2-dev
Operating System:
Ubuntu Linux 18.04 LTS
Issue:
Latest unstable version of Neovim installed via Ubuntu PPA repository has stopped editor window displaying as shown in screenshot.
Expected behavior:
Editor window to present cursor and Neovim interface.
Actual behavior:
Blank space where Neovim editor window should be as shown in screenshot.
Steps to reproduce:
Updated recent version of Neovim unstable using PPA, opened Oni.
Current version of Neovim unstable shown in screenshot.
Dowloaded
20180924-oni_error
20180924-nvim_unstable

@oni-bot

This comment has been minimized.

oni-bot bot commented Sep 24, 2018

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.

@justinmk

This comment has been minimized.

justinmk commented Sep 24, 2018

What does :ls! show?

Maybe equalsraf/neovim-qt#417 is related.

@PaleAugust

This comment has been minimized.

PaleAugust commented Sep 24, 2018

As attached in neovim. I can't run the command in Oni as there is nowhere for me to enter the command...
20180924-ls

@justinmk

This comment has been minimized.

justinmk commented Sep 24, 2018

Oh, probably not equalsraf/neovim-qt#417 then.

Maybe neovim/neovim#9024 is causing this somehow, though it was intended to prevent this very issue.

@CrossR

This comment has been minimized.

Collaborator

CrossR commented Sep 27, 2018

If nobody else has given this a test, I can try out some nvim versions this weekend and see if the later versions are causing this issue.

There is the "debug.neovimPath" option that can be used to point to any nvim executable to test it without installing anything else. This includes a .exe on Windows, and AppImages on Linux.

@CrossR

This comment has been minimized.

Collaborator

CrossR commented Sep 30, 2018

I've given this a test and confirmed it on the latest nightly - neovim/neovim@6e146d4

I gave the PRs and Following HEAD docs a quick read, and then poked in Oni and it looks to be the way Oni was (hackily) getting notifications if neovim was blocked on startup.

This was done here:

private async _checkAndFixIfBlocked(): Promise<void> {
Log.info("[NeovimInstance::_checkAndFixIfBlocked] checking mode...")
const mode: any = await this._neovim.request("nvim_get_mode", [])
if (mode && mode.blocking) {
Log.info("[NeovimInstance::_checkAndFixIfBlocked] mode is blocking, attempt to cancel.")
// The UI is blocked on some error message.
// Let's grab the message and show it, and unblock the UI
await this.input("<esc>")
const output = await this._neovim.request<string>("nvim_command_output", [":messages"])
Log.info("[NeovimInstance::_checkAndFixIfBlocked] sent esc, getting command")
this._onMessage.dispatch({
severity: "error",
title: "Problem loading `init.vim`:",
details: output,
})
} else {
Log.info("[NeovimInstance::_checkAndFixIfBlocked] Not blocking mode.")
}
}

I'm assuming the mode check fails due to their not being a buffer at first.

Looks like we need to remove that, and to surface the errors in a different way, before we then call nvim_ui_attach. We could possibly do the work around specified in the PRs to preserve the old behaviour until this is implemented, so that Oni is usable for people who are following HEAD.

Any input @bryphe / @Akin909 ?

@justinmk

This comment has been minimized.

justinmk commented Sep 30, 2018

Looks like we need to remove that, and to surface the errors in a different way, before we then call nvim_ui_attach

I don't think so. Rather, don't surface the errors at all, let Nvim do it. The purpose of neovim/neovim#9024 is to fix the issue in Nvim so that UIs don't need to do things like "nvim_command_output", [":messages"].

We could possibly do the work around specified in the PRs to preserve the old behaviour until this is implemented, so that Oni is usable for people who are following HEAD.

What workaround are you referring to? I think no workaround is needed with Nvim HEAD. Instead, some old code in Oni could be removed.

@CrossR

This comment has been minimized.

Collaborator

CrossR commented Sep 30, 2018

I don't think so. Rather, don't surface the errors at all, let Nvim do it. The purpose of neovim/neovim#9024 is to fix the issue in Nvim so that UIs don't need to do things like "nvim_command_output", [":messages"].

Ah! That makes sense then.

What workaround are you referring to? I think no workaround is needed with Nvim HEAD. Instead, some old code in Oni could be removed.

That would be passing both --embed --headless, as currently Oni needs to support both the bundled version of Nvim (0.3.1) and people following HEAD, and I assume if we delete our code currently it will cause issues for people that are running versions without the PRs merged. When we update to 0.3.2, then we should delete the old code, but for now I think we need to support both which could be a bit more awkward.

That said, I guess we can just get the nvim version and only run the hacky code for older versions, and have HEAD not run it and let nvim surface everything.

@justinmk

This comment has been minimized.

justinmk commented Sep 30, 2018

That would be passing both --embed --headless

I don't follow. If Oni is not already using --headless then there's no reason to add it. --headless is for non-UI clients.

That said, I guess we can just get the nvim version and only run the hacky code for older versions, and have HEAD not run it and let nvim surface everything.

Yes, exactly. That might require invoking nvim an extra time to get the version (Edit: version is a field in nvim_get_api_info, so no extra nvim invocation is needed.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment