Does not start on macOS

[caeu]

Neovide does not start on macOS after updating to (today's commit dd74ff). The window pops up and closes almost immediately, logs shows ERROR Neovide requires nvim version 0.4 or higher while I have 0.6.1

Old version works (from a week ago)

To Reproduce
Start nevoid from command line or application

• OS: macOS 12.1
• Neovide Version 0.8.0
• NVIM v0.6.1

LOG
TRACE [neovide] Neovide version: 0.8.0
DEBUG [neovide::settings::window_geometry] Loaded window settings: Windowed { position: PhysicalPosition { x: 1280, y: 1080 }, size: Dimensions { width: 106, height: 41 } }
TRACE [neovide::renderer::fonts::caching_shaper] Using font_size: 28.00px
TRACE [neovide::renderer::fonts::font_loader] Loading font FontKey { bold: false, italic: false, family_name: None }
TRACE [neovide::renderer::fonts::caching_shaper] Font width: 17.23px 17.36px
TRACE [neovide::renderer::fonts::caching_shaper] Fudge factor: 0.99
TRACE [neovide::renderer::fonts::caching_shaper] Fudged font size: 27.63px
TRACE [neovide::renderer::fonts::caching_shaper] Fudged font width: 17.00px
TRACE [neovide::renderer::fonts::font_loader] Loading font FontKey { bold: false, italic: false, family_name: None }
INFO [neovide::window] window created (scale_factor: 2.0000, font_dimensions: Dimensions { width: 17, height: 35 })
TRACE [neovide::redraw_scheduler] Next frame queued
TRACE [neovide::redraw_scheduler] Next frame queued
TRACE [neovide::renderer::fonts::caching_shaper] Shaping text:
INFO [neovide::bridge::command] Starting neovim with: Command { std: "/bin/zsh" "-lc" "\x1b]1337;RemoteHost=ommited@ommited\x07\x1b]1337;CurrentDir=/Users/ommited\x07\x1b]1337;ShellIntegrationVersion=12;shell=zsh\x07/usr/local/bin/nvim --embed", kill_on_drop: false }
ERROR [neovide::bridge] Neovide requires nvim version 0.4 or higher. Download the latest version here https://github.com/neovim/neovim/wiki/Installing-Neovim

[fredizzimo]

It looks like it detected the path of nvim wrong"\x1b]1337;RemoteHost=ommited@ommited\x07\x1b]1337;CurrentDir=/Users/ommited\x07\x1b]1337;ShellIntegrationVersion=12;shell=zsh\x07/usr/local/bin/nvim, instead of just /usr/local/bin/nvim

My guess is that /bin/zsh -lic "which nvim" outputs more than just the path to nvim, but I don't have any Mac Os system myself to test. I think we could drop the -i(interactive) parameter, so it becomes /bin/zsh -lc, but I'm not sure if that will change the outcome or not.

[caeu]

When I run which nvim I get /usr/local/bin/nvim
Same when I run /bin/zsh -lic "which nvim" I also get /usr/local/bin/nvim
Also the same if I drop the i

NB. nvim is symlinked, homebrew installation. not sure if this is relevant.

[fredizzimo]

Yes, that looks right.

But INFO [neovide::bridge::command] Starting neovim with: Command { std: "/bin/zsh" "-lc" "\x1b]1337;RemoteHost=ommited@ommited\x07\x1b]1337;CurrentDir=/Users/ommited\x07\x1b]1337;ShellIntegrationVersion=12;shell=zsh\x07/usr/local/bin/nvim --embed", kill_on_drop: false } looks very strange. It's hard to tell if it is right or wrong, because it's dumping the whole Tokio::process::Command struct, instead of just the command, so I'm not sure what Neovide is actually trying to run.

For the information, the command it should run in this case is /bin/zsh -lic "/usr/local/bin/nvim --embed"

One workaround worth trying is to start Neovide with neovide --neovim-bin /usr/local/bin/nvim

[caeu]

Same when running nevoide --neovim-bin /usr/local/bin/nvim

[fredizzimo]

I looked a bit closer and it does appear as if the launching actually succeeds. Since otherwise it would output 'Could not locate or start neovim process'

neovide/src/bridge/mod.rs

Lines 47 to 60 in dd74ff4

	async fn start_neovim_runtime() {
	let handler = NeovimHandler::new();
	let (nvim, io_handler) = match connection_mode() {
	ConnectionMode::Child => create::new_child_cmd(&mut create_nvim_command(), handler).await,
	ConnectionMode::RemoteTcp(address) => create::new_tcp(address, handler).await,
	}
	.unwrap_or_explained_panic("Could not locate or start neovim process");
	// Check the neovim version to ensure its high enough
	match nvim.command_output("echo has('nvim-0.4')").await.as_deref() {
	Ok("1") => {} // This is just a guard
	_ => {
	error!("Neovide requires nvim version 0.4 or higher. Download the latest version here https://github.com/neovim/neovim/wiki/Installing-Neovim");
	exit(0);

Which probably means that the output pipe is broken, or that --embed was not passed correctly.

I described a similar issue in the pull request for the similar behaviour on WSL #1118. If the startup scripts launches a subshell, then /bin/zsh -lic nvim --embed enters an interactive prompt instead of actually launching nvim and capturing the output.

Do you have something like that in your .zshrc that could explain it?

[caeu]

I don't have related to nvim in . zshrc but maybe my nvim configs or plugins?
Still, I thought this has to be specific to this built, because I reverted back to an older Neovide, and it works fine.

[fredizzimo]

Yes, something broke with that change, but at the moment it's unclear exactly what it is. other than that it appears as if the stdio pipe between the launched neovim and Neovide is not working correctly.

I don't think it's related to any plugins, but something in the shell configuration could explain it.

[caeu]

Alright, I will stay on the older version for now, I am happy with it.
If you keep this issue open so I can test it when a fix is proposed here.
Otherwise, you can close it since this might be specific to my computer. I will try future builds anyway.

Thanks 🙏

[Kethku]

But INFO [neovide::bridge::command] Starting neovim with: Command { std: "/bin/zsh" "-lc" "\x1b]1337;RemoteHost=ommited@ommited\x07\x1b]1337;CurrentDir=/Users/ommited\x07\x1b]1337;ShellIntegrationVersion=12;shell=zsh\x07/usr/local/bin/nvim --embed", kill_on_drop: false } looks very strange. It's hard to tell if it is right or wrong, because it's dumping the whole Tokio::process::Command struct, instead of just the command, so I'm not sure what Neovide is actually trying to run.

This makes me doubt this whole approach :(
The code \x1b]1337 is a terminal color code. And the rest looks sorta like a prompt or something. So likely shelling out to the users terminal is causing us more grief here than benefit.

The real issue is I don't know enough about Macos to know what the "correct" way to get a user's binary should be. Part of me wonders if we should just go look at what alacritty does and defer to their strategy.

@fredizzimo what do you think?

[Kethku]

https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences#screen-colors for reference

[fredizzimo]

I don't think Alacritty is a good reference, since they actually want to start a real shell. In this case we just want to run a shell command from outside of it.

I think what we need is for someone to run /bin/zsh -lc 'which nvim', outside of a shell, and see what it outputs. If that's not possible, then at least try it from within a shell and verify that it outputs just the path without any prompts as it should.

[Kethku]

Just to add, we also need to verify that it doesn't output any ansi codes as those are a large part of why the above output is gummed up

[caeu]

Just to add that I tried on a clean environment (new login user) and it works.

[fredizzimo]

Just for the reference, in Windows, running the following command
wsl /usr/bin/zsh -lc 'which nvim' from the command or powershell prompt outputs just the path and returns back to the command prompt. And that is with a quite complex powerlevel10k prompt.

[fredizzimo]

Just to add that I tried on a clean environment (new login user) and it works.

That seems to indicate that there's something in your profile or .zshrc files that makes it incompatible. Could you try to comment things out until it works?

I can also think of another approach. And that is Neovide itself could be launched from within the shell. At the startup it detects if it's launched from the shell or not, if not, It launches another instance inside the shell, and exists the original one.

Edit: That approach would also simplify the code, since we can assume that we are running inside a shell, and all platforms could handle command line, which and exists the same way, so no special case handling is needed any more. The only thing needed is a small check at the startup, to detect if it should re-launch inside a shell or not.

[caeu]

Even when I try to start Neovide from finder, it doesn't work, which I think suggests that it not .zshrc.
Could it be something related to iTerm2 shell integration which I have installed along with iTerm2? I trying to find out how to correctly remove it.

[fredizzimo]

@caeu, The more I think about it, the more I think we should try the other approach, which does not rely on redirecting output across shells. So unless that doesn't work, there's no need for you to test further, and possibly mess up your system.

[cserb]

Just adding: I have the same issue with the same output, just that it's fish shell

INFO [neovide::bridge::command] Starting neovim with: Command { std: "/usr/local/bin/fish" "-lc" "\x1b]1337;RemoteHost=cristian@xxx.local\x07\x1b]1337;CurrentDir=/Users/cristian/Downloads/neovide/target/release\x07\x1b]1337;ShellIntegrationVersion=5;shell=fish\x07/usr/local/bin/nvim --embed", kill_on_drop: false }
ERROR [neovide::bridge] Neovide requires nvim version 0.4 or higher. Download the latest version here https://github.com/neovim/neovim/wiki/Installing-Neovim

[fredizzimo]

Actually, I think WSL still needs to be special cased. Because we are forced to launch the second Neovide instance like this wsl neovide.exe --parameters, or possibly wsl ${SHELL} -lic 'neovide.exe --parameters which means that it launches a windows executable, so the full environment does not follow. But on MacOS, I think the approach will work.

[caeu]

@fredizzimo You are right, I disabled the shell integration of iTerms2 from .zshrc and .bash_profile and Neovide starts ok.

[cserb]

@fredizzimo You are right, I disabled the shell integration of iTerms2 from .zshrc and .bash_profile and Neovide starts ok.

Can you give a bit more context? I didn't understood what to do to make it work

[fredizzimo]

@cserb, for now I think it's better that you stay at an older build without the issue, until we git this properly fixed. Users should not have to edit their shell startup scripts to use Neovide. At least not unless they have something very special, and then also have the knowledge to make the behaviour conditional depending on if running from Neovide or not.

[Kethku]

I'm very much at a loss for how to do it otherwise though. @shaunsingh do you have some ideas? I know you mentioned some concern with this approach in the original PR

[fredizzimo]

@Kethku, I described the approach here #1175 (comment).

I might have time to do it tomorrow, but I’m not sure. But if you understand what I meant, feel free to try before that.

[fredizzimo]

Or actually, maybe it’s even more simple than that. If application shortcut or whatever it’s called could be made to start ${SELLL} -lic ’neovide —params’, intead of neovide directly.

It still needs modification to Neovide, basically to remove all the special handling, so that it works like Linux.

[fredizzimo]

I don't have time to do anything about this today, but I think the best option is to write a shell script wrapper https://mathiasbynens.be/notes/shell-script-mac-apps, with a very simple shell script
${SHELL) --lic neovide` (this will launch neovide within a login shell environment. That means it should have the correct environment set, and nvim in the path. The alternative is, as I explained before to have the Neovide itself perform the same operation and re-launch itself.

Neovide also needs to be changed to support running like this, since the custom platform_which and similar don't work, They should all be removed, and the Mac version should work exactly as a regular Linux version. So WSL remains the only special cased code.

The crucial difference between this approach and the current main version, is that there's no redirection across shells, so no matter what customizations they users have done, it should work.

I think at least the shell script, and packaging part needs to be done with someone on a Mac. The removal of the Mac specific code, can be done either me, when I have time or someone else.

[Kethku]

This helps a bunch and gives enough info for me to take a look. I'll try to get to it tonight.

[jonsmithers]

FWIW I did a git bisect to find the commit where neovide no longer starts for me on MacOS, and it's dd74ff4

# git bisect bad
dd74ff42394ac2f309108ccc0f53674cfaa8525b is the first bad commit
commit dd74ff42394ac2f309108ccc0f53674cfaa8525b
...

[Gregory-Bach]

@jonsmithers worked for me to checkout to db53e94
Thanks!

[zhaozg]

Same, mark.

[goldcoders]

#1230 This might do the trick on your issues! on macOS M1
neovide Im also facing before

[djmaxus]

Still have the same issue on latest version of nvim and neovide: the latter just does not start.

Macos 10.14.6

What is the solution to this problem after all? It's pretty hard to track through the lots of comments of this thread

[bmulholland]

@djmaxus This issue was resolved, and it's been working for me for months. If you're on the latest neovide, and it's still happening, then the issue is something else.

[djmaxus]

@djmaxus This issue was resolved, and it's been working for me for months. If you're on the latest neovide, and it's still happening, then the issue is something else.

@bmulholland , thanks!

It seems that you're right.

After some more careful consideration, I found out that I did not add nvim to PATH before launching neovim.
Now I can launch it via terminal, but cannot do that by clicking an app, which may be resolved by myself in the same manner

[scarin]

you can try this cmd:
neovide --geometry 10x10

it work for me ... save my life

[owittek]

On a M1 Mac my issue was that neovide did not find my nvim installation in the /opt folder (due to homebrew) so I symlinked nvim ( ln -s /opt/homebrew/bin/nvim /usr/local/bin/nvim ) to not pollute my path and everything works fine now.