[RFC] TUI (Terminal UI) remote attachment - GSOC 2019

[hlpr98]

The aim of the project can be summarized as:
Whenever the user starts Nvim as nvim --connect {addr} the Nvim will connect to the Nvim server listening to {addr}, here {addr} can either be a pipe address (a.b.c.d) or a tcp address (a.b.c.d:port). The Nvim client instance would send input to the remote Nvim server and reflects the UI of the remote Nvim server. So the Nvim client acts like any other external GUI.

The final goal of this project is to make TUI and nvim server to run as separate processes and communicate with each other over RPC channel. This also results in removal of ui_bridge completely.

TODO

• support for --connect
• TUI to send nvim_attach call through rpc channel
• Send user inputs to Nvim server through the rpc channel
• Handlers for redraw events from Nvim server
  • generate methods to handle each individual ui events
  • make/generate dictionary to store the ui event handler methods
  • make the handle_ui_redraw
  • convert grid_line to raw_line before feeding it into tui
  • handle client resizing
  • client exits with server
  • check conversion of grid_line to raw_line
• Add functional-tests for --connect feature.
• Removal of ui_bridge to make TUI a rpc client
  • TUI client (when started with --connect) works without ui_bridge
  • correcting the anomalies seen
    • Abort trap 6: when no server is present
    • :set termguicolors makes blank part of screen white --checked only on iTerm)
  • Making builtin TUI work without ui_bridge
    • Starting nvim --embed job from TUI and connecting to it as a client
    • Passthrough arguments to nvim --embed instance
    • Make sure application stops even if the --embed is killed
    • Add nvim_read_stdin() API to support reading from a non-tty stdin
    • Allow GUI-client to let server know when focus is gained
    • Allow setting of the options: term_name, term_colors and term_background
    • Get the exit code of server at the client
    • Get bracketed paste for large inputs working
    • Get echo xxx | nvim to work (now echo xxx | nvim - works)
    • Get suspend-restart of TUI to work

[hlpr98]

Support for --servername has been completed. And the TUI is now able to send nvim_ui_attach to server.

[ilAYAli]

• Are there any plans to split up the TUI and nvim core code, so these can be built separately (maybe as a TUI submodule?)
• What do you or someone with relevant insight, think about, by default, letting the client start the server (if it is not running and --server(name) is not specified on the CML), and automatically use the local server instance?

[hlpr98]

The current scope of the project is to first make TUI perform remote attachment, I.e provide it the capability to become rpc client and later completely remove ui_bridge so that nvim server and TUI can be run in separate processes instead of thread.

So to answer your question...once this project is completed, the TUI (when the nvim is started without --servername) should connect to local server running on the predefined namedpipe or ip as an rpc client and should run as a different process from that of the server.
And as for building tui and server code separately... I don't have enough knowledge yet to think of its uses and disadvantages.

[hlpr98]

Here is a short demo of the current progress.
Things completed:-

• Support for --servername
• User inputs passed to remote server
• The redraw events from server handled at client side.

Things to be completed:-

• The grid_line needs to converted to raw_line before feeding it into TUI so that the text from server is shown at the client site.

[bfredl]

Are there any plans to split up the TUI and nvim core code, so these can be built separately (maybe as a TUI submodule?)

I don't really see the benefit. We still want just running nvim to provide the same user experience, by transparently starting the server instance and the TUI process from the same binary (perhaps using early fork() on POSIX systems).

[ilAYAli]

Are there any plans to split up the TUI and nvim core code, so these can be built separately (maybe as a TUI submodule?)

I don't really see the benefit. We still want just running nvim to provide the same user experience,)....

I envisioned making the TUI client just an other consumer of the RPC API - which I guess will be the preferred communication method for GUI’s as well? If so, is there a need for the tight coupling between the server and TUI?

[bfredl]

I envisioned making the TUI client just an other consumer of the RPC API - which I guess will be the preferred communication method for GUI’s as well? If so, is there a need for the tight coupling between the server and TUI?

Not sure I see the problem here. The "tight coupling" is just that the TUI is always available with nvim as a default user interface, is this not reasonable? The RPC API used will be the same. What would be the benefit of isolating the TUI as a new C project in a separate repo? Perhaps exposing reusable client code in libnvim would be useful for external GUI:s, but this could just be a build from the nvim codebase.

[ilAYAli]

I envisioned making the TUI client just an other consumer of the RPC API - which I guess will be the preferred communication method for GUI’s as well? If so, is there a need for the tight coupling between the server and TUI?

Not sure I see the problem here. The "tight coupling" is just that the TUI is always available with nvim as a default user interface, is this not reasonable? The RPC API used will be the same. What would be the benefit of isolating the TUI as a new C project in a separate repo? Perhaps exposing reusable client code in libnvim would be useful for external GUI:s, but this could just be a build from the nvim codebase.

It is not unreasonable as that is how the majority will use the project. I am thinking more in terms of how to organize the code, or as you mention, “exposing reusable client code in libnvim”; having the TUI as a separate directory, or pulled in as an essential requirement (like libuv).
If this is still a goal: https://github.com/neovim/neovim/wiki/Refactor-vim-into-a-library, having TUI logic in the library smells somewhat wrong. The TUI should be a first class citizen, showcasing how to use the library.
However, there might be good reasons not to split the code, RPC overhead on some supported platform(s), ...?

[bfredl]

It is not unreasonable as that is how the majority will use the project. I am thinking more in terms of how to organize the code, or as you mention, “exposing reusable client code in libnvim”; having the TUI as a separate directory, or pulled in as an essential requirement (like libuv).
If this is still a goal: https://github.com/neovim/neovim/wiki/Refactor-vim-into-a-library, having TUI logic in the library smells somewhat wrong. The TUI should be a first class citizen, showcasing how to use the library.

Reorganizing the code is fine, and something we will need to do to some extent to enable a public libnvim at all (i e separate public and internal headers). What I mean is that we can reorganize the code just fine within the same codebase and build system. I fail to the point of dealing with it as a separate repo or submodule or essential requirement or whatever.

[ilAYAli]

It is not unreasonable as that is how the majority will use the project. I am thinking more in terms of how to organize the code, or as you mention, “exposing reusable client code in libnvim”; having the TUI as a separate directory, or pulled in as an essential requirement (like libuv).
If this is still a goal: https://github.com/neovim/neovim/wiki/Refactor-vim-into-a-library, having TUI logic in the library smells somewhat wrong. The TUI should be a first class citizen, showcasing how to use the library.

Reorganizing the code is fine, and something we will need to do to some extent to enable a public libnvim at all (i e separate public and internal headers). What I mean is that we can reorganize the code just fine within the same codebase and build system. I fail to the point of dealing with it as a separate repo or submodule or essential requirement or whatever.

I think that we are agree, my main concern was some logical separation of libnvim and TUI.
One reason for having a submodule is to have the possibility of different release cycles etc due to e.g RPC API versioning, but there are other ways to manage that.

[bfredl]

I think that we are agree, my main concern was some logical separation of libnvim and TUI.

Sure, but it will be easier to discuss this as part of a larger plan for separation of libnvim from the rest of nvim at all. Currently libnvim is all of nvim except main() is renamed nvim_main() :)

The RPC API is already versioned separately from nvim release version.

[ilAYAli]

I think that we are agree, my main concern was some logical separation of libnvim and TUI.

Sure, but it will be easier to discuss this as part of a larger plan for separation of libnvim from the rest of nvim at all. Currently libnvim is all of nvim except main() is renamed nvim_main() :)

The RPC API is already versioned separately from nvim release version.

+1 :)

[hlpr98]

Here is a short demo of the current progress.

Things completed:-

• Support for --servername
• User inputs passed to remote server
• The redraw events from server handled at client side.
• Converting grid_line to raw_line
• Handling resizing of TUI
• Use of a simple light weight loop when in client mode instead of entering normal_mode
• Client exits with server

Things to be completed:-

• Removal of ui_bridge

Things to be checked and tested:-

• Conversion of grid_line to raw_line
• The functioning of new light loop created for client

[pinpox]

Did remote connecting to a headless nvim ever get implemented?

[bfredl]

It will for 0.6

[mattpallissard]

Is this still slated for 0.7? This feature would be incredibly useful in the HPC space (you submit a headless nvim instance as a job to a batch scheduler) as well as for headless hardware development.

I took a look at the source branch, it looks like there have been some structural changes (like argument parsing) since that original work was done. Happy to chip in and take a crack at the rebase if someone with more context hasn't planned on picking this up already and they were willing to give a high level overview on what's changed since the original work was done.

also, more than willing to rtfm if there are any relevant docs or specific PR's to take note of.

[bfredl]

I'm working on rebasing this. Getting this fully merged will done for the 0.8 cycle (focus for 0.7 will be now be to stabilize already merged features, which are a-plenty), though I plan to do this incrementally so we can get something to a testable state early in the 0.8 time frame. #17691 as the first basic step.

[orlandosh]

Noob question: how would the clipboard be handled in that case? Also, which init.lua would be loaded on the client side? both? It would be nice if we could, for example, load both environments and execute scripts both from the server and from the client.

[dundargoc]

https://neovim.io/roadmap/

[justinmk]

How does it work when multiple TUIs connect to the same server? ... if each get their own cursor etc, then this will seamlessly allow collaborative editing,

It works just like any other Nvim GUI/UI frontend. All connected UIs share the same (server-side) cursor.

This PR has nothing to do with cursor management nor collaborative editing.

[FilBot3]

Throwing this out there.

• https://containers.dev/

The spec seems to have been released for VSCode's DevContainer functionality from what I understand.

[justinmk]

Merged in #18375