Neovim-qt: Condition for checking when in nvim vs. nvim-qt

[james2doyle]

Is there a variable or if statement I can do to tell when in nvim vs. nvim-qt?

[equalsraf]

Not at the moment. I've been thinking about it a bit, we could set a variable on attachment and unset it on detach. Ultimately this should be fixed when the issues pointed out in #50 are fixed upstream (neovim/neovim#3646).

[equalsraf]

In a nutshell there are limitations to what can be done, and I'm not able to cover all the cases, usually one of two things happens when launching the GUI

1. nvim-qt _spawns_ the nvim process - in practice nvim first reads init.vim and then accepts a connection from the GUI
2. nvim-qt _attaches_ to an already running nvim process

In general checking for the GUI presence when parsing init.vim is not very reliable, because for all intents and purposes it might not be _attached_ yet (event if nvim was launched by the GUI). Some people use autocommands to defer GUI configurations (see #95) but these are not exactly ideal yet. One of the possibilities is that Neovim will load something like ginit.vim when running a GUI.

Onward to what can be done right now:

Option 1 The GUI could set global variables on attach and detach. But this would not helo with init.vim. And in general I dislike this, because its to fail to unset the variables on detach (connection errors and crashes do happen).
Option 2 The GUI sets an environment variable when spawning the nvim process. Works for init.vim, but it does not work at all when attaching to a running nvim.
Option 3 Source a predetermined file after the GUI attaches successfully. Maybe the GUI order loading of ginit.vim. There are a couple of corner cases here too, like what happens if we attach multiple GUIs, or when attach and detach multiple times?

Personally I'm slightly more fond of Option 3 because it seems it could be mostly compatible with future Neovim behaviour. Option 2 is by far the easiest, it likely solves what most people want (an easy check in init.vim) but it will likely be broken later on. The detach behaviour is still unclear to me.

ping @jpleau because he asked the same question in gitter.

[lambdalisue]

In general checking for the GUI presence when parsing init.vim is not very reliable, because for all intents and purposes it might not be attached yet

But I think has('gui_running') or whatever is useful to make a compatible vimrc. For example, I'm using Vim plugin manager which has _lazy_ implementation and I do want to source plugins for GUI automatically for neovim-qt but neovim. In this case, neovim-qt does not necessary to be attached at that moment.

So generally I think Option 2 is required at least.
But I also don't think Option 2 is enough, as you pointed out.

What about GUIEnter autocmd for additional option? Like calling that autocmd every after GUI attaches.
In native Vim, it is called only once but I think it's OK to call it multiple times while users can easily make a code sure to be called just once like:

autocmd GUIEnter *
    \ if !exists('g:loaded_something') |
    \   let g:loaded_something = 1 |
    \   call s:do_something() |
    \ endif
" Or just remove autocmd in GUIEnter

I just wonder while it's just a design matter but if there is GUIEnter, I can do whatever I want with that autocmd... (Option 3 can be done by user as well).

Or maybe GUIAttached autocmd which internally spawn GUIEnter once for the first one.

[justinmk]

I mentioned on gitter (yesterday) that we will probably add UIEnter or UIAttached (whose v:event will contain information about the UI being attached). Though this will not be exactly equivalent to GUIEnter: e.g., GUIEnter is documented as firing _before_ VimEnter, which will not be the case for us.

[lambdalisue]

GUIEnter is documented as firing before VimEnter, which will not be the case for us.

Aha, sorry I didn't understood the event correctly.
UIEnter or UIAttached sound brilliant :-)

[equalsraf]

FYI right now the best way around this is to move GUI specific initialization into ginit.vim. The file does get loaded on each attachment so be wary of that.

[equalsraf]

Closing this, for now best way to deal with this is move GUI specific code to ginit.vim.

[haifengkao]

neovim-dot-app use a custom variable neovim_dot_app to deal with this issue (https://github.com/rogual/neovim-dot-app/issues/91).

[haifengkao]

My current solution is to add "gui_running" to static void f_has(typval_T *argvars, typval_T *rettv) in eval.c. Then build nvim from source.
The nvim in console shows some strange graphics, but neovim-qt works perfectly.

[equalsraf]

neovim-dot-app use a custom variable neovim_dot_app to deal with this issue (rogual/neovim-dot-app#91).

At runtime you can check for the existence of g:GuiLoaded but this is not 100% foolproof. The variable is set by the GUI shim plugin, it doesn't guarantee the GUI is running only that the Gui commands are available for use - https://github.com/equalsraf/neovim-gui-shim/blob/master/doc/neovim_gui_shim.txt#L46

One case when this check clearly fails is if the GUI detaches from Neovim. Given that the attachment is not permanent, reasoning about a permanent gui_running state like we do in Vim doesn't make much sense. Its easier to consider GUI attachment as an event (GUIAttached/Detached events have already been discussed upstream as a way to handle this) for now the only mechanism we have is using one of the following

1. nvim-qt does its best to load the GUI shim plugin
2. the GUI shim sets g:GuiLoaded (event if the GUI is not set)
3. nvim-qt always processes ginit.vim (regardless of 1. and 2.)

We still have no mechanisms to handle detachment, but thats ok for now, we can probably consolidate that upstream.

[chrisbra]

coming here from vim-airline repository (vim-airline/vim-airline#1259). It seems like it is not possible to differentiate between nvim and vim-qt. I would however need that information. What is the correct solution to that problem currently?

[razor-x]

I have been using ginit.vim to load extra config for neovim-qt.

[sgoranson]

I have been setting a temporary environment variable to differentiate nvim/vim in my scripts....

alias nvim-qt="NVIM_GUI=1 nvim-qt"

if(!empty($NVIM_GUI))
do stuff
endif

[fcying]

Can I use &term == 'nvim' to check this?
If I use nvim-qt, &term also is nvim, use nvim, &term is xterm-256color