I don't know what the alternative would be here. VSCode's SSH edit works surprisingly well, and I stopped fiddling with vim, nano, or micro on my remote machines long ago.
The agent gets out of my way and lets me work in peace. It almost feels like I'm working from my local machine—a huge win in my book.
This could be a security risk, but the development experience is unmatched. I couldn't care less which other editor VSCode is killing, as I mostly don't care about my tools as long as they get out of the way and let me do my job.
The alternative is suggested by tramp, which from what I know treats the remote as a network filesystem instead of an execution host. I don't believe that tramp deploys any binaries: it reads and writes bytes over pipes and all meaningful execution happens locally. Notably, it does not achieve persistence, because there's a difference between "VSCode plugins have access while you're SSH'd in" and "VSCode plugins have access forever".
When you’re in a buffer displaying a remote file, most commands take that in account and execute in the remote context. And more often than not, that means connecting through pipes (and files) inside the ssh tunnels. Eglot (with gopls) works fine and fast for me. Executing ‘shell’ opens a remote shell, as well as launching tasks through compilation mode. Grepping and finding files, as well as dired also work fine.
Persistence is important to me, and making it read-only significantly reduces its usefulness. I regularly SSH into a dev machine to run scripts and update configurations. As long as a tool lets me do that without getting in my way, I'm good with any solution that works.
Tramp is perfectly able to write, it's just that it does it by writing a temp file locally and then using ssh to transfer the file to the remote, rather than installing a copy of itself on the remote and acting through that. It only uses executables that it finds on the remote. So if make and gcc and sed and such are available it's basically transparent, indistinguishable from local editing except for network round trips, and the only changes it leaves behind are the files you edit.
Then tramp would be a perfect fit for you as long as you’re willing to learn emacs. If you open a remote file, almost all actions when that buffer is selected will execute in the remote context (launching commands, visiting directories, opening a shell,…)
You don't know what you're missing then and I'm not sure such opinions count. It's probably for the best to refrain from criticizing things one has no experience in.
Not wanting to pick up a tool isn't criticism. I just said that I couldn't care less. It's an editor. I work mostly with VSCode and a sometimes with Goland or Intellij and don't think about them too often. Editor wars are lame and old; so are linter and formatting wars.
That's an issue with any plugin system, right? AFAIK no IDE has a plugin system with capabilities or a sandboxed interpreter.
VSCode does have a thing where it's like do you trust the authors of this project. Not sure what it does because I've never had to use it. From StackOverflow[1]:
>If you select No, I don't trust the authors, Visual Studio Code will open the workspace in 'restricted mode'. This is the default for all new workspaces. It lets you safely browse through code but disables some editor feature, including debugging, tasks, and many extensions. However, keep in mind that 'restricted mode' is all you need for many use cases.
Actually if restricted mode[2] is any good, vscode might be better at security than most other editors/IDEs.
> Actually if restricted mode[2] is any good, vscode might be better at security than most other editors/IDEs.
Unfortunately, it’s not. Restricted mode is VSCode without any plugins. That means that unless you’re doing very basic TS development (I think that’s the only language VSCode supports out of the box), then you’re kinda hosed.
Yeah, I'm all in for a more secure option as long as it allows me to do everything that VSCode's SSH agent does. But if the devex goes down the drain because of "security" then I'm good for now.
From what I’ve seen, my colleagues using vscode are hampered in ways they don’t recognize because they have no concept of how good things could be. Working with multiple remotes, they’re often completely unaware of which one they’re connected to or what state their connection is in. Their terminals are laggy and session state persistence is inconsistent. It’s just a massively worse experience than tmux + a real text editor. Plus the server is a real pig and they often end up running half a dozen server instances because the server doesn’t terminate properly. And then, half the updates break and they lose an hour because they don’t know how to ssh into the host with a real ssh client and clean up the busted vscode server.
I'm not sure what features VSCode offers exactly, but I find sshfs works quite well for remote editing of a bunch of stuff. I think it should basically be the same as VSCode?
Why is that? How much data are we expecting the LSP to ingest?
For most projects my expectation is that all the source code gets quickly cached on my machine, and from then on querying a local LSP is much faster. Especially with high-latency connections.
That doesn't work if the remote is a different platform or architecture. Also, part of the point of running remotely is to do compute on the remote (often a powerful workstation or server), not locally.
You can use sshfs if you like. But there are many use cases where you have to do things remotely.
For languages like Rust, the language server does compilations — it has to run on the remote because it has to know about OS/arch-specific details.
There's a bit of latency between when you type and when the language server shows or hides the squigglies. But it's less than the time it takes to compile stuff anyway.
One fewer tool to think about. It remembers the connections and instantly gives you access to a full-fledged editor on a remote server. It just works, and I don’t think about it twice, which is a huge win in my book. I’m good with the trade-offs.
It’s still not quite the same thing because it feels like you’re literally sitting at the remote machine; the code completion is there using an LSP that doesn’t have to pay a network cost, executables run locally which means you can be on a local Windows and remote Linux or vice-versa, and all in a super easy to use package that auto-restores the session whenever you come back even if you’ve put the machine to sleep.
By comparison, I’d say doing things over sshfs and terminals is the fiddling part.
Absolutely. It worked fine before vscode existed and it will work fine when the next hot button IDE comes along. I'm not sure why people keep reinventing the wheel and creating themselves new problems!
The agent gets out of my way and lets me work in peace. It almost feels like I'm working from my local machine—a huge win in my book.
This could be a security risk, but the development experience is unmatched. I couldn't care less which other editor VSCode is killing, as I mostly don't care about my tools as long as they get out of the way and let me do my job.