Comment by miki123211
2 years ago
> there are a few things that VSCode doesn’t give us.
> The first is that a TUI IDE is excellent for work on remote machines—even better than VSCode. You can SSH into any machine with ease and launch the IDE. Combine it with tmux and you get “full” multitasking.
I definitely disagree with this sentiment. At my last job, I had to do most of my work on a remote server (because it had a GPU), and I found VS Code far more pleasant to use than plain old SSH. People recommended using an editor on the server side or freaking around with Win SCP / Cyberduck, but VS Code was just so much better in so many ways.
Because of VS Code's web roots, it can easily run its frontend on your own local computer while running its backend somewhere else. This means that most common actions, like moving the cursor or selecting text, can be done locally, without the need for a round trip to the server. The operations that do have to be executed remotely, like saving a file for example, are properly asynchronous and don't interrupt your workflow. Everything is just far snappier, even if you're working from home, through a VPN, on barely working WiFi and an ADSL line.
As a bonus, you get fully native behavior and keyboard shortcuts that you'd expect from your platform. Things like text selection and copying just work, even some of your addons are carried over.
100% agree. Remote VSCode over SSH is great.
The resource consumption on the client doesn't bother me one bit. Any minimally decent laptop can put up with that load, on battery power, for hours.
I would agree with “whatever it takes to make the server install leaner, more portable, etc” just without sacrificing many features.
If the server side doesn't run on FreeBSD that's really too bad. If Microsoft makes it hard to improve by not making those bits open source, that's very unfortunate.
VS Code remote in some cases is better than local.
As the remote can be a docker container, so when I have to do some experiment, I create a container takes 5 min to setup. I than can play around, test dozen packages and configs, once I am comfortable commit last version.
If I want to do some quick testing on project by different team, again a local container is setup in 2-10 mins. Once done delete the container and my local system isn't messed up.
Last is obvious use case if you want to test anything on reasonable large data or GPUs. Create a cloud server, get data run your code, tests. Push data to S3 and done.
vscode's model of server on host is good because of low latency.
It can be a bit heavy in cpu usage depending on plugins though.
I like emacs tramp in theory since it doesn't impose that, but latency suffers.
With correct ssh config it usually works well, but many times I'd prefer lower latency with emacs being on the host.
That's supposedly possible, but I've never gotten it working.
What were you trying to do with tramp? I’ve used it for coding Common Lisp, together with a remote SLIME session - ie slime-connect - and while I have run into at least 1 limitation with paths, I have a decent enough work around for it. I think the setup was just a matter of setting some customizable variables.
2 replies →
I was doing exactly the same 30 years ago with X Windows and XEmacs.
> This means that most common actions, like moving the cursor or selecting text, can be done locally, without the need for a round trip to the server
No, you weren't doing this. You were making a round trip to the server when you moved the cursor or selected text.
> You were making a round trip to the server when you moved the cursor or selected text.
Of course this being X, your machine ran the server and the remotes were the clients…
No, as gummy well putted it, all of that was done on the client computer.
4 replies →
There’s some confusion in some of the replies here. The point this person is trying to make is that you get the remote machine’s key bindings, not the local’s. That’s an artifact of the experience being a remote desktop.
It's similar in outcome (doing "stuff" remotely), but not the same architecturally.
VScode runs on the computer in front of you, and it _does not_ send key-presses or other user input over the network at all. Instead VScode sends file-changes over the network to the remote, and executes commands on the remote (e.g. SSH's in and runs 'gcc ...').
With X, XEmacs is not running on the computer in front of you; it's running on a computer far away. Every key-press and mouse click must be transmitted from the computer in front of you over the network, received by the remote computer, then a response sent from the remote to the computer you're interacting with, where it'll be displayed.
You still had to do a roundtrip for every single click though, right? I don't think X Windows has any kind of client side scripting system.
That's better than SSH for sure, but still not as good as the web model.
X Windows server runs on the client machine.
The client is the server application.
19 replies →
Even in 2023 you can get vim to be more powerful than VS Code. But it's that much more difficult.
As the author states, IDEs haven't necessarily gotten a lot better, but imo advanced features have become a lot more accessible.
What does it mean "more powerful" ? Do you mean in terms of productivity ? It probably depends on your task anyways. In 2023, it's still a pain to have decent debugging in Vim. For pure text editing, I can believe you, but for software development, I highly doubt it.
> Even in 2023 you can get vim to be more powerful than VS Code. But it's that much more difficult.
I absolutely agree, assuming you're using "powerful" in the same sense as saying that a Turing machine is more powerful than a MacBook.
Vim is a text editor, not a code editor. It has always been fundamentally designed this way.
1 reply →
In the spirit of what the person you are replying to wrote, you really weren't doing the same thing 30 years ago, because X Windows doesn't really have the capabilities vscode has for remote work. X Windows approach is very primitive compared to what vscode does.
https://en.wikipedia.org/wiki/X_Window_System_protocols_and_...
https://code.visualstudio.com/docs/remote/remote-overview
Emacs can edit files remote to where Emacs runs with e.g. TRAMP. Emacs can also run remote to where the X server runs. Those two are entirely orthogonal to each other.
> I definitely disagree with this sentiment. At my last job, I had to do most of my work on a remote server (because it had a GPU), and I found VS Code far more pleasant to use than plain old SSH. People recommended using an editor on the server side or freaking around with Win SCP / Cyberduck, but VS Code was just so much better in so many ways.
I'm not familiar with VS Code setup for remote editing. Does it run LSP on remote and give you full hints, errors, etc. locally?
> As a bonus, you get fully native behavior and keyboard shortcuts that you'd expect from your platform. Things like text selection and copying just work, even some of your addons are carried over.
Selecting text with Shift+ArrowKey or something like that is not a "bonus", it is just a bad text editing experience. Keyboard shortcuts are the way they are on Vim/Emacs not because their developers can't figure out how to bind Ctrl+C/Ctrl+V...
> I'm not familiar with VS Code setup for remote editing. Does it run LSP on remote and give you full hints, errors, etc. locally?
Not sure about other languages, but when I use VS Code to develop Rust remotely, it prompts me to install the rust-analyzer extension (which is my preferred LSP server for Rust) to a remote whenever I'm opening a project for the first time. VS Code is able to distinguish between extensions that need to be installed on the same machine as the code (like the LSP server) and extensions that are just making changes to the local UI.
> Selecting text with Shift+ArrowKey or something like that is not a "bonus", it is just a bad text editing experience. Keyboard shortcuts are the way they are on Vim/Emacs not because their developers can't figure out how to bind Ctrl+C/Ctrl+V...
I use an extension for vim keybindings in VS Code. When connecting to a remote host, the vim plugin still works fine, itand doesn't prompt me to install anything on the remote side, since the changes are synced to the remote host at a much higher level than that (i.e. locally mapping "dd" to "delete this line from this file" and sending that to the remote rather than sending the remote the keystrokes "dd" and having the remote determine how to interpret it).
My understanding follows (I don’t use it but I’ve noticed the processes running on other people’s machines). Corrections welcome.
It’s split into a client (web frontend) and server that’s doing all the work. The server can be run anywhere but it’s effectively a bunch of stuff installed in a docker container. When you start an instance for a project, it creates a container for that instance with all the code folders etc bound in. LSPs are running in that container too.
It’s possible to use your own image as a base (you might have custom deps that make installing the requirements for an LSP hard, for example).
The trick they use here is that there’s some base container/volume that has most of the server stuff downloaded and rest to go. Whether you start a normal instance or from a custom image they do it the same way by just mounting this shared volume and installing what they need to bootstrap the server.
It also appears they create a frontend window per server process too. So the master client process starts, you select a project folder, they create a new server container and a new client window connected to it. The frontend client is local while each server can be anywhere (obviously you could run the client with X if you wanted to further muddy that).
I use that all the time in my hobby tinkering pseudo cloud server on a odroid SBC. It feels like I'm literally on that specific computer directly. Plugins like docker work as well
I've been wanting to try something like that with neovim's remote features, but haven't found the time. Has someone attempted this? If so, how successful was it?
I've always been a big user of powerful laptops because I do like the mobility (allows me to work/browse stuff outside my home office) and I dread the pains of properly synching my files across a laptop and desktop (not only documents/projects, but also configs and whatnot).
`nvim scp://devhost/main.c`
Using the editor on the server from a remote connection is silly. However VSCode is not unique. On my local Emacs I use ssh via tramp [0] to browse files on the server and then edit localy. HOWEVER I also have physical access to my server. Emacs then gives me the added benefit of being able to run in terminal on the physical server without any window manager installed.
[0] https://www.gnu.org/software/tramp/
> Using the editor on the server from a remote connection is silly.
In my experience, this is the best way to do remote work. The alternative is to either not work with remote resources (data, hardware, etc), work locally and sync changes to remote, or work locally with a remote mounted file system (unless you need remote hardware).
For the parent, they needed GPU access, so they had to run remotely for hardware access.
I normally need particular data that is too big to move locally, so I like to work remotely for that reason. I could remotely mount drives via an SSH Fuse mount, however the IO speed for this method can quickly become a problem. For me, it is a much better experience to either use a remote web editor (rstudio server), VSCode remotely (which is a remote web editor over ssh), or vim. With web based remote editors, you still draw the screen locally, but get updates from remote. And more importantly, compiling and building takes place remotely.
I find this method much better than either pure remote access (VNC/RDC/X11) or local-only editing with syncing code and/or data. But it very much depends on your work. When I don’t need to work with remote data, a locally managed Docker devcontainer provides a much better development experience.
In my experience, it's the worst way to do remote work. There are so many better solutions.
If TRAMP is too slow, just mount the remote filesystem locally using FUSE somehow. Use SSH to run processes on the remote system like compile and run the program. No need to run the text editor on the remote system.
You can also do it the other way around: have your remote system load your local data. I developed a small bare metal OS this way. Ran the cross compiler locally, had the output go to some NFS mount which was also available via TFTP. Booted the target system with PXE.
Running a text editor on a remote system is good for one off things and maybe as a last resort, but that's it.
12 replies →
I worked at a place that had a half built distributed system that we still needed to use (many bidders buying Ad space from a API based market). one great thing with tramp is that you can tramp into multiple systems simultaneously. So you are editing say files from 5 different systems (tweaking the yaml or whatever) at the same time. You could then start eshells on each of those systems at the same time. It made it really easy to adjust the settings and restart multiple apps really quickly (big screen, 5 files on top, 5 shells on bottom). I always get a kick out of people saying "you use that! you need to switch to editor X it has feature Y!" And me thinking yeah, that feature has been in emacs since before you were born. it is getting a bit crufty in its age though. Its main attraction is for people who like LISP. There a project called lem (IIRC) that is rewriting it in much higher performance Common Lisp.
Absolutely: https://lem-project.github.io/ Works for Common Lisp out of the box (it's a Lisp machine) and for other languages (LSP client).
> Using the editor on the server from a remote connection is silly.
Why?
Constant screen redrawing and input lag.
2 replies →
Tramp is quite slow though, IMHO, and last I used it Emacs very much expects file access to by synchr.
Tramp has like four backends, try sshfs if ssh is too slow
This ability also proves useful when trying to do complex package management in an isolated manner with ROS; I ultimately used a remote vs code shell running off the robots OS to just have my ide recognize the many local and built dependencies that requires a full ROS setup.
I wish I could find a decent way to make VSCode work properly on Android.