Add a bridge between the embedded nvim and another nvim instance

[tfer]

This is more a feature request than an issue.

If I understand correctly, the editing takes place in the embedded neovim instance's buffers which are invisible and the windows in vscode are just coupled to those buffer in such a way as to make it appear the editing taking place in that window. I'd like to have the ability to see that buffer in its raw, nvim state. This would mostly be for development and troubleshooting.

A similar thing, but to different ends, would let you switch between editing the vscode window with focus over to editing it in another instance of nvim, (gui or terminal). That instance could have it own plugins (which won't have to be constrained to only those plug-ins that are compatible with vscode). Perhaps this "bridging" could use the mechanism of your invisible buffer rather than a strictly file system based one.

Tom Fetherston

[trkoch]

I did some experimentations (for debugging purposes) going in the same direction. Perhaps this extension could be enhanced to take NVIM_LISTEN_ADDRESS into account.

[samvv]

Good idea!

That instance could have it own plugins (which won't have to be constrained to only those plug-ins that are compatible with vscode)

Unfortunately, that won't work, because the method that is currently used is actually doing almost exactly what you described. The difference is that this extension spawns the nvim process, instead of you. If too many Vim-specific plugins are loaded, chances are it breaks the VSCode integration. In theory, you could manually load additional plugins after you have 'switched' from VSCode to the terminal.

Perhaps this extension could be enhanced to take NVIM_LISTEN_ADDRESS into account.

Actually, I'm going through the sources and just now discovered that this extension recognises NEOVIM_DEBUG_HOST and NEOVIM_DEBUG_PORT. So if you set NEOVIM_DEBUG=1 and NEOVIM_DEBUG_PORT=4000 it will try to connect to tcp://127.0.0.1:400.

[thomazmoura]

Actually, I'm going through the sources and just now discovered that this extension recognises NEOVIM_DEBUG_HOST and NEOVIM_DEBUG_PORT. So if you set NEOVIM_DEBUG=1 and NEOVIM_DEBUG_PORT=4000 it will try to connect to tcp://127.0.0.1:400.

So, does that mean that we could connect to a NeoVim instance running on a tcp port (with something like nvim --listen 127.0.0.1:6600) instead of a path and it would already work with this extension? Or it doesn't support anything like it at the moment?

Right now I'm trying to fully "containerize" my neovim setup but I still need to run an instance on WSL2 for things like VS Code and Azure Data Studio. But if I could connect through tcp I could use Docker's neovim instance instead and keep all my NeoVim setup on containers. Is it currently possible?

[neimanpinchas]

I would use it for editing over ssh, since vscode ssh extension has many issues

[theol0403]

There is a new neovim ui session api which could be used here, to attach to buffers remotely.