You can turn off a load of stuff. You don't have to install any plugins.

VS Code has one as far as I am aware uniquely-implemented feature -- remote editing -- which is absolutely invaluable to me as a freelancer with many long-term, infrequently-updated projects.

Lots of separate VM dev environments with different editor configuration and tool requirements, and more or less only SSH config and keys to connect me to them, from whichever machine I need to.

It's the only Microsoft thing I use at the moment. I don't even have a github account.

Jetbrains Gateway offers remote editing as well. It's still Beta and certainly has some rough edges, but it works ok-ish as a daily driver and is actively developed. The last update few weeks ago even added Dev Containers support (to an extend).

https://www.jetbrains.com/remote-development/gateway/

Ooh, that's interesting, thank you.

> VS Code has one as far as I am aware uniquely-implemented feature -- remote editing -- which is absolutely invaluable to me as a freelancer with many long-term, infrequently-updated projects.

To be that one guy, Emacs has had remote editing (without even needing to install anything on the remote server, unlike vscode) for forever with tramp mode. But other, more accessible/modern editors having it is definitely nice because it's such a handy feature

I guess Tramp mode must be the inspiration, to some extent.

But the VSC approach allows me to customise the tool environment within the remote extension, including going as far as using different SCSS processors and language servers, but is managed through essentially exactly the same interface as the local.

(It's also inherently multi-user; changes are reflected in each machine connected to the remote, which makes it really easy to move from a work to a home machine, or a desktop to a coffee-shop laptop.)

This is what I meant by uniquely-implemented. I often find that the most visceral critics of VSC or adherents of "natively implemented" code editors haven't the slightest awareness of this feature.

Still -- thank you for your comment, it gives me one more thing to investigate for those times when tools fail me.

Yeah, I certainly didn't mean it as a slight against VSC. (I am very much an electron hater but VSC is an exception because they obviously put in the effort to make it work as well as it does.)

Much as I love Emacs I do mostly use VSC these days, and I do tend to forget the extent of what remote editing capabilities it provides since I haven't had much reason to use them in a while.

Yes -- sorry, my comment about critics may have come across as aimed at you, but it wasn't!

I was thinking more of all the other times this has come up in the past and I have to say, "you understand it's not just a text editor with network access?"

It has pretty much unique capabilities, and as another commenter has said, it's even remarkably agnostic as to the _kind_ of remote container. For example you can run the editor on Windows with the remote as WSL, and it really blurs the boundaries between them in a way that cannot possibly be a coincidence for Microsoft.

Everyone always brings up Emacs with regards to VS Code's remoting features, but I have yet to see anything that supports that it is anywhere close to VS Code.

With VS Code, I can develop across Windows, Docker, Linux, Linux running on WSL, and macOS with zero configuration aside from setting up SSH connection configs and installing the remote extensions with a button click. All the extensions work seemlessly when remoting. My settings also automatically sync by just signing into GitHub.

With Devcontainers, I don't need anything to develop except Docker and VS Code. I simply pull down a repository, open it in VS Code, and then VS Code sets up a container with all dependencies and configuration.

No, Emacs does not have this experience.

And I don't know the technical reasons why VS Code installs on the remote server, but I think it's important to note that you're not just editing remotely but developing remotely.

Ah right.

(Embarrassed cough)

So, er, I didn’t need to install MacOS Fuse, mount an SSH-FS folder and then use VS Code to open my remote code for editing then?

Thanks for sharing. At least I’ll know next time! :-)

Ohh you're going to enjoy this when you get to it :-)

To also be that one guy, emacs has had this with the ssh method in TRAMP basically since ssh existed. (Not the devcontainer stuff, it has something similar, but it wasn't till LXC/Docker got popular that emacs could do it that way. At least on Linux) I agree, it's amazing and great that more people are finally using this methodology, but certainly not new to VSCode

No one said it is new. It's that the experience isn't replicated by anything else, including Emacs, unless someone has a video demonstrating it that doesn't including hours of setup and years of experience with Emacs and is as seamless as it is in VS Code and gets the same ongoing support.

> it's amazing and great that more people are finally using this methodology

Okay. (Emphasis mine.)

We get it. Emacs is awesome and has been around a while. But not everybody started with it when there were no other competing tools, but now there are competing tools.

Even if emacs can handle the remote editing side I doubt the remote debugging experience comes close to what vscode can offer with very little effort.

I do all my development on remote supercomputers and the ability to remotely debug multi-process Python and C++ applications running inside containers across many servers made me love vscode.

Personally zero configuration is not a selling point for me for a professional tool I rely on to do maybe the majority of my work.

I think it’s reasonable to not hold hours or even days of setup and learning against a product I’d use in this fashion. Even a tiny 1% productivity benefit obtained after configuration and learning earns me about 2.5 dev days worth of benefit every year. And if I expect to use the tool for a decade that’s almost a month.

Why does something require setup or configuration if it just works though? How is that not a selling point? Requiring hacking to get some, now standard behavior, is not a virtue. VS Code can be configured via settings for both VS Code itself and extensions and can be extended all you want via custom extensions. It's not like VS Code doesn't support extension. It supports it rather heavily. It just comes with a huge amount of stuff out of the box that doesn't require years of hacking a .emacs file.

I don't want to install a new tool and be told I need to dump hours and days into it when another dev tool just does it where I can get on with doing what I want to do. This is exactly why I went to VS Code from Emacs.

Are you talking about Live Share? JetBrains also has collaborative sharing, inspired by Live Share.

Even though I primarily use WebStorm, when I’m working with people on a contract gig, I frequently use Live Share as a pairing tool whether to help debug something or just for training/mentoring.

No. Though it’s the basis for the live sharing mechanism as well.

I’m talking about the remote dev environments. Editing inside VMs, inside WSL, inside Docker containers or via SSH to remote machines, where the editing environment runs seamlessly on the remote, can have extensions, can do version control, run language servers etc.

https://code.visualstudio.com/docs/remote/remote-overview

Basically a part of the editor is running remotely, and yet can be managed as if it were local (e.g. an extension can be installed locally or into the remote). So your code is operated on entirely by the remote.

It is, as far as I am aware, unique in its scope.

Another great feature is the refactoring plugins, haven't seen that in any CLI editors

I didn't want to move away from Sublime Text, so I made a continuous sync tool for remote editing. I've been using it for quite a while now and it works pretty well. https://unisync.sh/

You can disable plugin suggestions.

Please tell me how.

> So I need 1-to be able to write text, 2-syntax highlighting.

If you just need those two things there's plenty of options - why are you forcing yourself into vscode ? VSCode is great because of the plugin ecosystem - if that's not your thing use something else - there's plenty of alternatives.

Vim