Keep the same neovim instance alive

[medwatt]

This is not a bug that I'm reporting, but I'm wondering if it is possible to keep the same neovim instance alive so that all captured windows use the same instance instead of starting a new one? This could help speed up opening neovim, as it doesn't need to load all plugins every time a window gets captured.

[Ghjuvan Lacambre]

Hi, thanks for opening this issue :).

This used to be possible, people requested it here: #197 and I implemented it in #382 . When I accidentally broke it in #506 , nobody complained and it took me six months to realize it was broken (#718). The low amount of usage this feature got means that it's not worth its maintenance cost.

This could help speed up opening neovim, as it doesn't need to load all plugins every time a window gets captured.

Neovim startup should already be as fast as possible - Firenvim pre-starts a neovim instance when you open your browser and the only delay in opening the Neovim frame is connecting to that instance over websockets.

[medwatt]

Neovim startup should already be as fast as possible - Firenvim pre-starts a neovim instance when you open your browser and the only delay in opening the Neovim frame is connecting to that instance over websockets.

Thanks for the swift reply. I use a plugin called ultisnips, which has a noticeable lag for the first time the Insert mode event is called. I currently face this issue when using firenvim as ultisnips gets loaded every time a textbox gets captured.

[Ghjuvan Lacambre]

A solution could be to have your neovim enter and leave insertmode when started by firenvim, e.g. by adding the following snippet of code to your init.vim:

if exists("g:started_by_firenvim")
    norm i<Esc>
endif

But I would really recommend dropping Ultisnips for something else.

[medwatt]

The above suggestion causes the firenvim plugin to die. Instead I use startInsert!. This spawns a python instance which checks the content of the buffer for snippets. This causes the slowdown to go. However, every time firenvim captures a new textbox, a new python instance gets created, which is killed when firenvim exists the textbox.

[Ghjuvan Lacambre]

The above suggestion causes the firenvim plugin to die

The suggestion was slightly wrong (it should be norm i instead of norm i<Esc>), but it shouldn't cause Firenvim to die unless starting ultisnips takes more than 10 seconds.

every time firenvim captures a new textbox, a new python instance gets created, which is killed when firenvim exists the textbox.

Is that a problem?

I'm going to close this issue because I will not implement workarounds for the bad user experience caused by other plugins, but feel free to reply and ask for more suggestions if you still need help :)

[medwatt]

Is that a problem?

I don't know. It's just surprising that if the plugins are loaded the first time firenvim starts, why do they need to be loaded every time a new text box is captured?

In any case, thanks for the help.

[Ghjuvan Lacambre]

Ah, sorry, I guess I wasn't very clear: while using a single a single neovim instance for all textboxes used to be a feature, I removed that feature due to nobody using it. In order to make sure that starting Neovim from firenvim is fast, Firenvim "pre-loads" an instance. When you select a new text box, Firenvim connects to the pre-loaded instance and a new pre-loaded instance is started, which will be used the next time you select a text box, which will make firenvim pre-load a new instance and so on and so forth.

So you effectively have a single instance per text box, it just gets pre-loaded. This explains why your plugin gets loaded multiple times and why you don't actually see that startup cost when clicking on a text box.

[medwatt]

Thanks for the explanation. I probably wouldn't have noticed this issue if I was using ultisnips, which I use because the lua equivalent (luasnips) is not fun to work with (takes too much effort, is unreadable, and doesn't support perl rejex).