search

onivim / oni

Oni: Modern Modal Editing - powered by Neovim
https://www.onivim.io
MIT License
11.35k stars 301 forks source link

Add server option to connect to specific nvim session #247

Open xelra opened 7 years ago

xelra commented 7 years ago

It would be great if ONI could add a --server option so that I can connect to a specific, already running session of Neovim.

That would also open up the possibility of using it in combination with SSH forwarding, to connect to remote Neovim sessions.

Bretley commented 7 years ago

Doesn't Neovim already come with a client mode? I'm not familiar with it, but it might be something to look into. If it's lackluster, this might be something to look into, but we don't want to rewrite a feature that might be improved later in neovim core

bryphe commented 7 years ago

Ya, I was wondering the same thing as @bert88sta - doesn't Vim have a clientserver mode already? Agree if Neovim is planning to support this, it'd make sense to have this in Neovim core. If not, we could create like a neovim-node-server that exposes the msgpack-rpc layer through a websocket, and Oni could connect to that. @justinmk might have context whether this is coming into neovim core, though.

xelra commented 7 years ago

You can tell Neovim to create a specific socket with NVIM_LISTEN_ADRESS, but the only client right now that can connect to that is Neovim-Qt with its --server option. It's a planned feature for Neovim too though.

How can this be moved to core functionality? Oni would always need the --server option or how else are you going to tell it to which socket to connect?

hassec commented 6 years ago

Hi @bryphe, has there been any more thought about adding this feature?
I saw #299 attempted this but was closed.

hassec commented 6 years ago

Hi guys,

I would actually like expand on this remote nvim idea. I think that this is a really great opportunity to enable true remote development.

Imagine the scenario which many of us probably share, where you mostly work/compile code on a powerful remote server/cluster.

To really have nice c++ autocompletion you editor will have to know about all the dependencies and the whole stack. Having all of this locally on my computer just isn't efficient and a huge burden.

As far as I know, there is not a single truly effective solution for an effortless workflow. I currently just run neovim with plugins serverside, which is great, but I would love to have a more modern UI (e.g tooltips, hover, peak to definition....).

Allowing oni to connect to a remote neovim would be a first step in the right direction of allowing you to edit your code from any computer no matter how powerful. Once that works, one would need to think about plugins... Like I said before the autocompletion should probably run on the host since that's where the code and CPU performance lies. But there might be extensions that make more sense locally.

So allowing a plugin to run either on the client or server would probably be the best.

Sorry for the long rambling, just figured I would leave this here. If this is something you guys would be open to investigate I would, of course, love to help!

Cheers

bryphe commented 6 years ago

Hi @hassec ,

Thanks for sharing your thoughts on this! Yes, I worked a bit on this in #299, but as I was thinking about some of the multiplexing scenarios more, I decided it needed a bit more thinking and tabled it. There's some prototyping I did around multiple neovim process hosted in Oni (like #622), and the remote-nvim idea fits in well with that. At the core, we really don't care too much how the neovim process is started - today we always open it via this startNeovim function: https://github.com/bryphe/oni/blob/83867d2f4f09aed4277d0649d8b5bde527a6d32e/browser/src/neovim/NeovimProcessSpawner.ts#L16

...but there really is no constraint there - the important part is getting the channel (right now, stdin and stdout to communicate with it).

It's really great that you called out and expanded on the scenario you're thinking about - like having your code live on a powerful machine and be able to run Oni/neovim from something more lightweight, like a chromebook or something.

So allowing a plugin to run either on the client or server would probably be the best.

In terms of the remote architecture, we'd have to think about this. Today, Oni hosts the language services separately from Neovim. So even if you had neovim run remotely, if Oni 'connected' to that remote instance, it would still be running the language servers locally. This would be problematic in a few ways - some of the language servers expect that the files for a project are local, too. In other words, connecting to a remote neovim instance would be relatively straightforward to add (it's really just changing the streams from stdin/stdout to something remote like a tcp socket), but it doesn't enable the rich UI integration.

Some there are a few considerations:

Following from the last point, an idea I don't think we've discussed yet would be taking advantage of the fact that we're running on a node/browser stack - Oni itself could provide a remote mode which would be a browser UI that interfaces back with a server it hosts.

This is different than the remote nvim idea because the entirety of Oni (language server, processing, etc) would be handled on the workstation, and the client would interface with it via a browser or an app. Latency would still be an issue, but this would allow for running the language server/plugins on the remote server and still get the benefit on the 'client'. This also would open up some interesting concurrency or pairing scenarios - like maybe I want to invite you to work on a file with me, and I could share out a transient link where you could edit with me in the browser.

Sorry for the rambling of my own 😄 Really appreciate your thoughts - I do think there are definitely some interesting possibilities & potential here!

hassec commented 6 years ago

Hi @bryphe, thanks for getting back to me :)

Have to admit that the idea of:

This also would open up some interesting concurrency or pairing scenarios - like maybe I want to invite you to work on a file with me, and I could share out a transient link where you could edit with me in the browser.

is something that I actually didn't really think about yet, but I love it. Of course like you stated this would mean having something like an oni-client and oni-server. Intuitively this seems like it would be quite a big change, no?

I would definitely be interested in trying something along these lines but want to be honest upfront that I would most certainly need some guidance. :D I tried to get a feel of how everything in oni works from an architectural and data flow kind of way but haven't been too successful. Is there maybe any hidden doc that I missed?

bryphe commented 6 years ago

Hi @hassec ,

Sure thing! Sorry for the slow response, been trying to wrap up the language integration pieces and get a website going 😄

Of course like you stated this would mean having something like an oni-client and oni-server. Intuitively this seems like it would be quite a big change, no?

Definitely would be a big change - we'd have to think about what responsibilities belong on each side of the client/server boundary. But there's cool possibilities, and I think that the current architecture is at least amenable to this.

I would definitely be interested in trying something along these lines but want to be honest upfront that I would most certainly need some guidance. :D

Awesome! It would great to have help! I'm happy to answer questions if you dig in. It might be worth picking up some smaller issues first to get an understanding of the code.

I tried to get a feel of how everything in oni works from an architectural and data flow kind of way but haven't been too successful. Is there maybe any hidden doc that I missed?

Sorry about this - there are a lot of moving parts and not a lot of documentation at the moment. I'd like to have some better architectural guidance. Some general starting points to look at:

The cool thing about the Redux architecture is it lends itself pretty well to pivoting to a distributed model - the NeovimEditor updates the rich UI primarily via UI.Actions, and those could just as easily be sent over a socket to a remote machine as run locally. Likewise, the NeovimInstance sends msgpack-rpc actions that could be sent over the wire to a remote machine too. Lots of possibilities...

Hope that helps get you started. Sorry there isn't more of an overview document - definitely something I'd like to have as the project matures!

tidux commented 6 years ago

Oni uses a web stack for its GUI. Why not flip the entire concept on its head and make Oni work in a browser tab over HTTPS? Think Eclipse Che, not Emacs+TRAMP. That would also allow distributing Oni-server as a Docker image that can be deployed and run directly on your dev server, on-prem virtual cluster, public cloud, or whatever. This also gets you Oni on ChromeOS, Oni on other Unixes, Oni on Haiku, Oni on AROS, Oni on mobile, etc. all for free.

EDIT: this would have limitations - things like Ctrl-W obviously don't work if the browser eats them and kill the tab -but it seems overall like a natural fit.

cvdb commented 5 years ago

Hi guys,

I use a file manager with curses interface like Midnight Commander of Vifm etc and I currently use neovim and NVR so that I can navigate files in VIFM and then open files into a single running neovim instance. This allows working with many related files.

I also use I3 windows manager so I usually have VIFM or MC in one pane and neovim in another side by side.

The file manager in Oni is not nice to use via the keyboard compared with MC for example so being able to open files from a terminal based file manager would be useful.

I tried to use an alias of nvim='nrv -s' but Oni still opens multiple instances from the command line.

The client-server concept @hassec mentioned does sound cool but I think it is a separate use case from opening multiple files in the same oni instance LOCALLY.

Cheers,

shaform commented 5 years ago

I think it would be exciting to have this feature. One of the major reasons people use vim/emacs is exactly because they need to work on a remote machine and current GUI setup support for this is not optimal (for example VNC/X11 forwarding is slow, the server might not have desktop environment, and sshfs is cumbersome).