Broken in neovim nightly

[jrnxf]

Describe the bug

Title says it all - I can't seem to get this to work at all. I'm running nightly neovim and haven't had any luck. By any chance would you mind taking a peek at my config and helping me diagnose what might be the problem? I'm curious if it has something to do with using lazy as my package manager, but it's hard to debug when I can't get anything to even happen.

To reproduce

If you clone [email protected]:jrnxf/dot.git and check out the tpipeline branch, you should be able to replicate

Of course you'll want to use my tmux and neovim configs. If you open up neovim with my config it should load everything on start. It might throw some errors but just exit out once and open it back up and you should be good to go.

Expected behavior

No response

Terminal emulator

iterm2

Debug output

No response

[jrnxf]

This is all I see running the debug function

[vimpostor]

I can't seem to get this to work at all.

Looks like your config works with neovim 0.8.3 but not with nightly. Bisecting neovim confirms that either 24488169564c39a506c235bf6a33b8e23a8cb528 or 43e8ec92de9e0850e7d202cb7ff9051bc408447e introduced a regression, where neovim causes the asynchronous background job to segfault. Both of these commits come from neovim/neovim#18375 and looking at the references at the end of that thread, that PR introduced a lot of other regressions, sigh...

Some of the regressions are very similar to this bug: neovim/neovim#21771

I will have to see how to fix this properly, but it probably requires upstream work.

[bfredl]

Some of the regressions are very similar to this bug: neovim/neovim#21771

Curious about this. what more state do you rely on being synchronized, apart from cwd as in the linked issue?

[vimpostor]

@bfredl It seems that your patch regressed detection of whether neovim runs in a GUI or in the TUI.

From the help page :h v:event:

			chan		|channel-id| or 0 for "internal".

However, after your patch this is no longer true. You can test it out with:

nvim --clean -Nu <(cat<<EOF
au UIEnter * echom v:event['chan']
EOF)

Before your patch this correctly displayed 0 (as per documentation). After your patch it returns 1 instead.

What is the recommended way to detect TUI neovim (as opposed to neovim started in a GUI) now? Please make sure to update the neovim help page (or fix it to return 0 again). The v:event['chan'] || has('gui_running') check for GUI does not work anymore.

[bfredl]

For the moment, I think the simplest way might be nvim_list_uis()[0].ext_termcolors which is true for a terminal. (though potentially there could be multiple UI:s attached, some of which are TUI:s)

[justinmk]

For the moment, I think the simplest way might be nvim_list_uis()[0].ext_termcolors which is true for a terminal. (though potentially there could be multiple UI:s attached, some of which are TUI:s)

For reference: has('gui_running') is now supported: neovim/neovim#22382