:connect current client to another Nvim server (dynamic detach/reattach, like screen/tmux)

[joshtriplett]

With nvim's terminal mode, if it had the ability to detach and reattach, it could serve as a replacement for screen or tmux.

This would require a few additional bits:

• A :detach function, to stop running the text UI and daemonize into a --headless instance that will survive the current user session ending.
• A command-line argument to list running nvim instances.
• Command-line arguments to attach to a running nvim instance and start the text UI. These need three variations: one that just fails if the session already has an attached text UI, one that detaches any attached text UI first (like screen -D -R), and one that attaches without detaching any other attached text UI (like screen -x). (That last one is optional, but I'd find it quite useful.)

cc @jameysharp

[justinmk]

See https://github.com/neovim/neovim/issues/2706#issuecomment-103715550

[gsf]

A lightweight way to do this at present that's working well for me is to let abduco handle the session management:

abduco -A nvim-session nvim

[lf-]

I'm currently using dtach for this: dtach -A /tmp/nvim-sess -ze '^q' -r ctrl_l nvim, but obviously I'm interested in this happening.

[justinmk]

reference for daemonize procedure:

• http://software.clapper.org/daemonize/
• https://stackoverflow.com/a/3095624/

[rashil2000]

Are there any plans for this? I use Neovim on Windows, but Windows lacks any terminal multiplexers (tmux works only in Msys2/Cygwin and that too only in mintty terminal).

Splits/panes etc. for shells works fine, but Neovim is obviously missing the main tmux feature that is attach/detach.

[aleksandersumowski]

@rashil2000 have you tried https://wezfurlong.org/wezterm/multiplexing.html?

[hoschi]

@rashil2000 original Veonim had that feature as well, here is a fork of it https://github.com/smolck/uivonim I don't know if there is another client implemented it which supports Windows.

[rashil2000]

@aleksandersumowski @hoschi Thank you for the suggestions, but what you're suggesting is totally different.

Wezterm is a terminal emulator which has splitting features. It is not a terminal application (and I can't install/use it on my Linux server). Tmux is a terminal application and can be worked on from remote also.

Uivonim is an IDE that uses Neovim as backend, from what I understand, so again, I don't see how it relates to tmux?

[hoschi]

@rashil2000 my point was that this feature is already implemented in core, but not in the TUI. Neovim is already split up into server/client. In a few works the TUI delivered by core spawns and connects to one Neovim instance. What you miss here is the ability to manage different servers, which is not implemented in TUI. Veonim implemented the server management. Unfortunately the original repository went away, here is a deep link to the functionality you want from my personal fork: https://github.com/hoschi/veonim/blob/master/docs/readme.md#multiple-concurrent-neovim-instances I guessed, but not researched, that the fork I posted has the same functionality and you can find it by reading the docs.

In general, I just suggested searching for a client which implements the management of multiple Neovim instances ... which runs on Windows. A starting point would be the wiki which lists different clients.

[rashil2000]

Oh, thanks for the explanation. Unfortunately, management of servers from the TUI is exactly what I was looking for (and I think that's what this issue is for).

I already use an excellent client for Neovim, called Neovide written in Rust. But this obviously requires a GUI.

This brings me to a question (forgive me if it's stupid): is it possible to connect to a Neovim server that's running on a remote Linux machine, from any of the GUI clients on my local machine?

[Benjamin-Davies]

Neovide has recently gained support for connecting to a remote Neovim instance over TCP (as detailed in the README). However, I don't think it's in the stable release, so you might have to build from source.

[rashil2000]

@Benjamin-Davies Wow, that looks interesting, will try building from source to check it out.

[lucc]

@rashil2000 there is the pr #8246 but it stalled for a long time now. I think that might be what you want.

[rashil2000]

There is actually another one on similar lines #10071, which allows the TUI to connect to a headless nvim server. While not exactly same as attaching/detaching, it will allow us to connect similarly to tmux servers (which can be listed by, for example tmux ls).

[nawordar]

This would be even more useful, if all instances could see the same opened buffers as it is possible with Emacs. This is something I miss from Emacs, as it allowed to use i3wm for managing window layout

[TamaMcGlinn]

I don't understand the original stated problem, because I have been using neovim and detaching / reattaching terminals for the past year, it works fine, and I haven't needed tmux ever since. I have some bindings to make this easier, but:

1) Open a split with a terminal inside 2) Start your long-running command 3) Quit the buffer with :q 4) Open the buffer again (:buffers or fzf :Buffers) 5) The long-running command is still going strong in there

[lucc]

@TamaMcGlinn the idea is not to use :terminal in one running nvim instance as a replacement for tmux but to "quit/detach" nvim itself. All buffers (even the :term buffers) are still running but you are back to the shell there you originally typed nvim to start neovim. Similar to :suspend but in such a way that the PID of nvim is not suspended but keeps running in the background ad hence can not be resurrected with fg from the shell but with some other command (like nvim --reattach or so). You could then even close your xterm window open another xterm widow and reattach to the still running neovim instance where all you buffers are still there. That is what they mean by "like tmux".

[TamaMcGlinn]

Thanks for the clarification, @lucc . It still seems useless to me, but perhaps you could sketch some usage examples? It seems to me that the only thing you can do with that setup but cannot do with :terminal is to have a long-running command executing in vim itself, not in a terminal. But I've never run a vimscript command that took more than 2 seconds to complete - probably because I tend to use a terminal to do compilation, rather than e.g. system('some build system') from inside vimscript.

There's a huge advantage to using vim containing :terminal buffers instead of tmux, because you can use all the normal vim-like commands over the terminal buffers, such as scrolling around, copying into multiple registers, closing and reopening of course, and moving the terminal between tabs / resizing it etc. - all of that becomes available to script inside the vimrc or using plugins. Another advantage is that all your action happens in one vim instance, so they all share buffers and copying and pasting and autocompletion over current buffer contents becomes a lot easier.

I actually do use tmux, a little bit, because it has a shared instance functionality (wemux) which makes it possible for a coworker to ssh into my machine and share screens / type together, much like VSCode's LiveShare. If NeoVim could offer that functionality simply using a plugin it could be great.

[rashil2000]

One use case of tmux that is not currently possible with vim:

I run a GPU instance on a cloud service, for training a model on a huge dataset. It takes like 3-4 days to complete. I ssh into the instance, start a tmux session, run my command there, detach from tmux, close the ssh terminal, and turn off my laptop. And I ssh again after 3 days, reattach to tmux, and carry on. Not possible with vim. Even if it's a task that takes significantly less than 3 days, this is a convenience that is too good to let go.

There's a reason tmux/screen are still so useful till date :)

[bfredl]

There's also https://github.com/martanne/abduco for just the session management part (which can be combined with nvim for the multiplexing part)

[lucc]

@TamaMcGlinn I think a use case (for me) would be something like emacsclient which allows me to run nvim --headless in a user systemd service and then connect and disconnect to this instance from different terminals.

EDIT: it seems abducto can be used for that as @bfredl said above. I had tried detach before with less success. Maybe it is time to implement my described solution with scripts ...

[hoschi]

@TamaMcGlinn Another use case is to switch between different projects more seamless without the need of saving/restoring sessions every time. At least I've had very few periods in the last few years where all plugins worked well together to look exactly like the original session again after a save/restore cycle.

[mark-i-m]

@TamaMcGlinn

I have a few use cases:

• I'm working on something on my machine in my office. I want to leave nvim running there and be able to ssh in from home and keep working without having to restart nvim the next time I come in to my office or reload all buffers or restart all plugins.
• In my office have I have multiple monitors and I use a tiling window manager. I would like to be able to open the same buffer on both monitors in different terminals without forcing one to be read only or having to refresh it.
• I use the rust-analyzer LSP, and it takes a lot of CPU and memory to run. If I open the same file in more than one terminal (eg from ssh), I get another copy of the LSP that can't benefit from an already running, already warm insurance. It both takes time to start and doubles memory usage. I would like to be able to reuse the LSP when I open the same file in another nvim instance.
• I have a lot of virtual desktops and sometimes I just want to edit a file quickly without hunting the desktop where I first open the file.

[hoschi]

@mark-i-m use case number two is actually a very good point I have not thought of yet, thanks!

[justinmk]

Status

Command-line arguments to attach to a running nvim instance and start the text UI.

✅ That works now: :help --remote-ui.

Todo

A :detach function, to stop running the text UI and daemonize into a --headless instance that will survive the current user session ending.

Detach via [count]<c-z> is implemented in https://github.com/neovim/neovim/pull/30319 . The "daemonize" step is always done on startup, so the server will keep running even if the ui client dies.

A command-line argument to list running nvim instances.

👍 also:

• sort by most-recent, so it's easy to reattach after detach.
• introduce :connect [address] which detaches the current UI and attaches to [address]. If [address] is not given, present a menu of known servers.

To support the "how swap" scenario (reattach the current UI client to a different server) I assume/hope that we can simply update ui_client_attach to accept an arbitrary channel: https://github.com/neovim/neovim/blob/a30afeeb85176b83f3f540851218165e5d9c4c47/src/nvim/ui_client.c#L83