TL;DR: the guy runs his dev env at home, then remotes into it with VSCode.
My question is about this:
I’m sure that the latency from, say, Australia will not be great, but editing in VS Code means you’re far less latency-sensitive than using something like VIM over plain SSH - all the text editing is still happening locally, and just the file saving, formatting, and terminal interaction is forwarded to the remote server.
Is there a neovim plugin of some sort that could do this? Replicate the stuff locally and then do synchronisation under the hub?
Yes, I’m aware, but I thought that reads/writes directly on the net. What the author in the post is saying, VSCode will make a local copy of the file, then all your operations are fast, and it will silently take care of the synchronization for you. So like if you were to :w the file, it might have some noticable latency, while in VSCode you would not see the latency - you just save the local file, and go on working, while Code does the sync.
I don’t think that this is what the author is saying. They seem to be saying that with vim over ssh, your keystrokes are sent over the network, so every letter you type gets round trip latency; when you edit with vscode’s remote support, the keystrokes stay local, and only saving and formatting goes remote.
It should be clarified that VSCode doesn’t do “file synchronization”. It does much more than that: all of the language support (indexing, completion, etc.) and many of the extensions you install run remotely too. I’m saying this because I often see it compared to Emacs’ tramp, and I do not think tramp does any of this… or at least I haven’t gotten it to…
I’m saying this because I often see it compared to Emacs’ tramp, and I do not think tramp does any of this… or at least I haven’t gotten it to…
tramp does execute most, if not all commands, remotely for remote buffers so things like grepping or LSP tend to work correctly via tramp if the tools are installed on the remote machine.
Does it? My most recent experience seemed to imply that things like the spell checker were running on my client machine, not the remote… And I’m not sure I ever saw it running rust-analyzer on the remote machine in the past. Is there any magic to configure?
This has some downsides too. It means that your remote machine has to be capable of running all of the developer tools. This is great for the Azure use case: your remote machine is a big cloud server, your local machine is a cheap laptop. It’s far more annoying for the embedded case: your local machine is a dev workstation, your remote machine is tiny device with limited storage, or possibly a smallish server with a load of boards connected to it.
Agreed, I was trying to use it to connect to a production server, not for main development but for quick tweaks. It installed so much stuff on the remote server that it slowed it way down. Scared me, didn’t try again.
Does it need to be a text editor feature? I haven’t used it for codebases of any great size but SyncThing is up to the job as far as I know; someone gave a lightning talk at PGCon 2019 about their workflow keeping an entire homedir mapped between two computers.
I use the VSCode remote stuff all day every day, but previously I used vim over ssh all day every day, so whatever.
Also, I sometimes use vi between the US and Australia and it’s really not that bad. I’d rather use something like vim that’s just a fancy front-end to ed/ex. Trans-pacific latency’s got nothing on a teletype…
Yes, I know and I do that occasionally. But I don’t think it would work if I had to do it non-stop, as my primary activity. The latency is barely noticeable but it’s there. I remember that from my operations days.
i love remoting to my big computer (32 thread CPU) from my little laptop for rust-analyzer
Even my big computer (hundreds of cores, hundreds of gigs of ram) is too slow for rust-analyzer :(
Works well for me on a 64Gb 32 core Framework. Maybe something else is going on?
A stupid large monorepo is what’s going on for me :-(
TL;DR: the guy runs his dev env at home, then remotes into it with VSCode. My question is about this:
Is there a neovim plugin of some sort that could do this? Replicate the stuff locally and then do synchronisation under the hub?
Original vim ships with netrw, which enables stuff like
:e sftp://example.com/file/path.c.I doubt that works with LSP or the like, however.
Yes, I’m aware, but I thought that reads/writes directly on the net. What the author in the post is saying, VSCode will make a local copy of the file, then all your operations are fast, and it will silently take care of the synchronization for you. So like if you were to :w the file, it might have some noticable latency, while in VSCode you would not see the latency - you just save the local file, and go on working, while Code does the sync.
I don’t think that this is what the author is saying. They seem to be saying that with vim over ssh, your keystrokes are sent over the network, so every letter you type gets round trip latency; when you edit with vscode’s remote support, the keystrokes stay local, and only saving and formatting goes remote.
Yes, exactly, I was a bit imprecise but this is the essence of my question.
It should be clarified that VSCode doesn’t do “file synchronization”. It does much more than that: all of the language support (indexing, completion, etc.) and many of the extensions you install run remotely too. I’m saying this because I often see it compared to Emacs’ tramp, and I do not think tramp does any of this… or at least I haven’t gotten it to…
tramp does execute most, if not all commands, remotely for remote buffers so things like grepping or LSP tend to work correctly via tramp if the tools are installed on the remote machine.
Does it? My most recent experience seemed to imply that things like the spell checker were running on my client machine, not the remote… And I’m not sure I ever saw it running rust-analyzer on the remote machine in the past. Is there any magic to configure?
Generally yes, see https://www.gnu.org/software/emacs/manual///html_node/tramp/Remote-processes.html for details
This has some downsides too. It means that your remote machine has to be capable of running all of the developer tools. This is great for the Azure use case: your remote machine is a big cloud server, your local machine is a cheap laptop. It’s far more annoying for the embedded case: your local machine is a dev workstation, your remote machine is tiny device with limited storage, or possibly a smallish server with a load of boards connected to it.
Agreed, I was trying to use it to connect to a production server, not for main development but for quick tweaks. It installed so much stuff on the remote server that it slowed it way down. Scared me, didn’t try again.
I use tramp in Emacs to do this; some brief searchengineering doesn’t find a vim version 🤷
I don’t use it, but vim-airsync has some stars and looks simplistic but perfectly plausible.
Does it need to be a text editor feature? I haven’t used it for codebases of any great size but SyncThing is up to the job as far as I know; someone gave a lightning talk at PGCon 2019 about their workflow keeping an entire homedir mapped between two computers.
Yes, there’s also use case for this. I was curious about neovim specifically in this case though.
I use the VSCode remote stuff all day every day, but previously I used vim over ssh all day every day, so whatever.
Also, I sometimes use vi between the US and Australia and it’s really not that bad. I’d rather use something like vim that’s just a fancy front-end to ed/ex. Trans-pacific latency’s got nothing on a teletype…
Mosh has helped me over a decade to deal with latency issues.
Yes, I know and I do that occasionally. But I don’t think it would work if I had to do it non-stop, as my primary activity. The latency is barely noticeable but it’s there. I remember that from my operations days.