Ask HN: Could VSCode be the new Emacs?

A Unix novice came to Master Foo and said: “I am confused. Is it not the Unix way that every program should concentrate on one thing and do it well?”

Master Foo nodded.

The novice continued: “Isn't it also the Unix way that the wheel should not be reinvented?”

Master Foo nodded again.

“Why, then, are there several tools with similar capabilities in text processing: sed, awk and Perl? With which one can I best practice the Unix way?”

Master Foo asked the novice: “If you have a text file, what tool would you use to produce a copy with a few words in it replaced by strings of your choosing?”

The novice frowned and said: “Perl's regexps would be excessive for so simple a task. I do not know awk, and I have been writing sed scripts in the last few weeks. As I have some experience with sed, at the moment I would prefer it. But if the job only needed to be done once rather than repeatedly, a text editor would suffice.”

Master Foo nodded and replied: “When you are hungry, eat; when you are thirsty, drink; when you are tired, sleep.”

Upon hearing this, the novice was enlightened.

EDIT - source: http://www.catb.org/esr/writings/unix-koans/shell-tools.html

I am familiar with sleep, but I haven't used the other two UNIX commands yet. I've still got a long road to enlightenment.

Don't worry. eat and drink are just old commands, but rewritten in Rust.

This is from Rootless Root: The Unix Koans of Master Foo - http://www.catb.org/esr/writings/unix-koans/shell-tools.html

Yes, thanks, should have mentioned that.

Are these fill-in-the-blank parables of some sort (or parodies perhaps)? I feel like I've seen every kind of story put in this format. Is there some historical context that makes these interesting?

They're in the style of old Zen parables. In fact, the line “When you are hungry, eat; when you are tired, sleep” is an old Zen saying.

https://en.wikipedia.org/wiki/Koan

This is the historical context: https://terebess.hu/zen/Mumon.pdf

Why it is historically and culturally significant: https://en.wikipedia.org/wiki/The_Gateless_Barrier

"Everything is a file"

Unix is an OS for I/O streams / lines. That's what it's good at. That's what the tools are designed for.

And that's how they spectacularly fail when something does not fit into that paradigm. Like file name with `\n`. Apparently now you need `\0`-separated lines and all the tools need `-0` or `-z` switches, console does not print it well and all that card house breaks apart.

Yup. It's a nice abstraction, but for many things an object-graph / object-stream makes more sense. The output / rendering can be a tree or a table.

Which is the reason I love PowerShell.

Missing the point, but imagine learning perl, sed and awk (and requiring everyone else to know all three) when you could just use Perl to do everything.

perl -pie 's/foo/bar/'

> But are there any other reasons, technical or otherwise, why people don't seem to use VSCode for things beyond editing code?

The best answer I've seen to this question is https://www.murilopereira.com/the-values-of-emacs-the-neovim...

Amongst other things, it lists different values that each tool prioritizes, and how "Core values are self-reinforcing. They attract like-minded people, who will then defend them."

Emacs: Extensibility, Freedom, Introspectability, Keyboard centrism, Stability, Text centrism.

VSCode: Approachability, Integration, Maintainability, Progressiveness, Velocity.

That is, even if VS Code achieves technical parity with Emacs (wrt introspectibility/extensibility), its community might not prioritize using VS Code for things beyond editing code.

Or maybe it will. These things are difficult to predict!

This is a great point, however the number of users of VSCode is so high (71% of StackOverflow users in 2021 [0]) that it's unlikely that it's only attracting users with a certain set of values.

[0]: https://insights.stackoverflow.com/survey/2021#section-most-...

Hey, thanks for the link, it was a really nice read!

> Velocity

Hmm not so sure about that. The main reason that I have not complete switched over to VS Code, is that it feel klunky and I'm using a 16GB macbook pro, not top of the line, but something where I should expect a code editor would feel not so klunky.

In the context of the linked article "velocity" is defined to be "Short and focused release cycles, aligned personpower, leveraging the community effectively". I think VS Code exhibits this value.

I started out with VSCode hoping it would be an easier, more modern Emacs. Calva was the closest thing to a good experience I could get. Now I am switching to Emacs for CIDER and generally the Emacs ecosystem.

I doubt I'll ever not use vim when I'm working/thinking in systems mode, though. The thought of waiting for a "real" editor to launch when I just want to edit a tiny unstructured file is a sad one to me.

If you're interested in a reliably-quick-to-start editor, and prefer the Emacs ecosystem, consider https://www.gnu.org/software/zile/ . It's built for that purpose.

I used to use a light editor for quick edits, jed, but now I use Emacs too. It turns out that Emacs in text mode without a full configuration (so: "emacs -Q -nw") starts nearly instantly on a few years old laptop, so I just aliased jed to this command. It's about ~110ms for start+exit, good enough for me. And all of Emacs is there, even my init if needed.

> The thought of waiting for a "real" editor to launch when I just want to edit a tiny unstructured file is a sad one to me.

Amen to that. That's why I use emacs. ;) Just timed it myself, started and ready to go in 120ms. Pretty sure we can shave more time off that.

>>Just timed it myself, started and ready to go in 120ms.

Let me get this straight. You plan to code for hours, and your biggest concern at this point in time is your editor takes 1 - 2 seconds more to start?

A second is 1.666666666667% of a minute. And 0.02777777777% of an hour. Just how much more productive are you getting by saving this time?

On the other hand emacs is notorious for making users spend days to get a decent working set up. And even that's more like bad vscode clone than anything else.

Programmer brains are weird, and are stimulated thoroughly by any and all optimization, especially ones that are impossible to not see

On the scale of reality, it's obviously less time to just pick up VScode in a few hours of learning (if that), and then deal with it taking 2-3 seconds to launch

But on the scale of programmer brain, it's clearly wayyyy better to invest days into learning emacs, writing custom configs for it, learning plugin ecosystems, and the like so that you can see and FEEL that 150ms startup every time.

That's ok if all you write is something like C or C++.

If you are writing html, css, react, js, python, sql and myriad other things. Then having all of this configured to your likings is a multi month project. While vscode gets you up and running in minutes.

Edit efficiency should be least of your worries. vscode constantly reminds me if I forgot to import something, or if I imported something and forgot to use it. It lets me navigate code semantically, not just through text tags. It lets me debug, have a project running on a remote box, and let me work on it like Im working locally etc etc. Writing a full feature list will make this a blog post/book.

At the end of the day my job is write code, not to work on side tooling projects.

> Let me get this straight. You plan to code for hours, and your biggest concern at this point in time is your editor takes 1 - 2 seconds more to start?

NO. Mine isn't. I happily used emacs when it took a solid half a minute to fully load. Hell, I once was stuck on an AIX machine that needed lots of maintenance and figured it would "save time in the long run" if I built emacs from source so I could debug things there instead of copying files back and forth. Eight megs and constantly swapping and I feel fine. :) I was just pointing out the startup time as an easy way to pop the nonsensical argument that on today's hardware emacs is anything but lightning fast.

> On the other hand emacs is notorious for making users spend days to get a decent working set up.

Days? Powerful tools can take years to master! The best are those which let you be productive immediately, while providing a natural and built-in path for you to grow as you need to. Make easy things easy, hard things possible, &c.

> Just how much more productive

It's naive to measure productivity in editor startup times when developer satisfaction is way more important.

Clearly this developer values shaving time off editor start time. Seems like it's a mistake to conclude they are concerned about recouping the milliseconds.

>>It's naive to measure productivity in editor startup times when developer satisfaction is way more important.

To be honest, I don't even notice what happens in 1 - 2 seconds.

Its like less than the time I take to sip my green tea.

And yeah more importantly. I don't kill vscode and restart it every day that's more like once in a few weeks.

I think Im ok sacrificing 1 - 2 seconds a month for the value vscode has to offer.

Let me correct you on one thing:

> VSCode: Approachability, Integration, Maintainability, Progressiveness, Velocity.

VSCode: Microsoft, Approachability, ~Integration~, ~Maintainability~, ~Progressiveness~, ~Velocity~.

> I constantly mis-press some weird key chord and enter a state where I can't do anything unless I restart the app.

C-g

> You can't just open a file, define a new hook or whatever and now your VSCode behaves differently.

By that definition of extensibility, even gEdit "could be the new Emacs".

> the main difference is that with Emacs you can start hacking any part of the environment right from the start. It's designed to be played with.

You just answered your own question.

Anyone who has ever made an extension for VS-Code knows that the amount of customization you can do is MINIMAL and tightly constrained. No, VS-Code won‘t be the next emacs, it is a text editor but nothing more. Emacs can be used as a whole operating system. It‘s the dame argument people had comparing Vim with Emacs. Both pieces of software are great but they serve different purposes.

Emacs selling point is that you can easily change any part of editor. You can introspect it, you can test your changes in the repl and commit them into your config file. And that happens almost immediately as you're starting to learn Emacs. I did not experience that workflow with vscode. It's more like vim for me and Emacs stands on its own.

Google is evil, everybody knows that (now) but young players don't know that Microsoft is also evil. Always was, always will be. Don't touch anything that Microsoft touched, you'll only get burned.

This warning goes double for all of Nadella's apologists who thought MS had somehow changed its stripes on open source.

> From what I understand, the main difference is that with Emacs you can start hacking any part of the environment right from the start. It's designed to be played with.

I think you nailed the big difference right there.

I mostly use vim but configuring the editor is a gateway to programming new functionality. You start small by defining a function bound to a key. Then you start exploring more of the api and gluing functions together. Eventually you refactor it a bit if you find it worth sharing.

I've only used emacs for a bit and I understand it has more of that "OS" aspect to it where people stay in their editor for a lot of tasks that are more than just"edit text". But like vim, users can tweak functionality in a relatively accessible and not overly-limiting way. And they are introduced to this early on.

I've used vs code. It's pretty. It works well. I have the impression that to change functionality I either have to hope it already exists as a toggle somewhere or go read how to write a full vs code extension. At least in my experience, it lacks the incremental aspect described above.

Visual Studio Code extensions are run at an arms-length from the core editor in an ExtensionHost sandbox. The OG Electron editor Atom is much more suitable as a 21st century Emacs architecture-wise, it allows extensions free reign. There is a big cost to this, it has suffered a lot of performance and upgrade compatibility problems stemming from this, so it's not strange that VS Code made the choices it did.

Practically speaking, now that VS Code extensions can present web views, they can be arbitrarily powerful as long as they don't need to mess with the editor's internals that is not exposed by the extension API. So making things like a mail reader or pixel editor is fine. Rearranging the whole UI is not.

Does VSCode offer a terminal user interface? With Emacs/Vim I can SSH to a remote machine and immediately start editing with muscle memory using the same keystrokes as in the GUI.

Sure VSCode has its strengths and as an IDE easier to get started and work with, especially for newcomers. That said, the fact that it requires a desktop environment to operate in means there are niches that Emacs fills which VSCode currently cannot.

> Does VSCode offer a terminal user interface?

Yes, but it's very buggy, and tends to drop both connections and characters all the time. If you're doing heavy terminal work you need an external terminal.

EDIT: actually I realised you were probably talking about running headless, whereas I was thinking of an integrated terminal. I don't believe vscode can run headless.

> Does VSCode offer a terminal user interface?

No

Can VSCode be used to SSH to a remote machine and immediately start editing with muscle memory using the same keystrokes as in the GUI?

Yes: https://code.visualstudio.com/docs/remote/ssh

With regard to vim, unless you've really hacked away at your .vimrc / init.vim, you can usually just apply the vim plugin to your editor and have an identical file editing experience. Interfacing with the file system / Git / operating system might of course differ - I personally use the editor's integrated terminal or a tiled terminal emulator for all that, so it makes no difference to me. This way I can use vim for ssh or editing config files, an IDE for programming if one is available for the given language, or VSCode for a preconfigured vim++.

Long term risk management!

99% of my time in front of the computer is spent in an editor (for both work and play). Having invested and continuing to invest so much time and effort in my tools and my environment, I would hate for something so fundamental in my life to not be free as in freedom:

    "Microsoft's releases of Visual Studio Code are licensed
     under this not-FLOSS license and contain telemetry/tracking"

    https://code.visualstudio.com/license

By choosing open source, you can reduce the amount of carpet pulled out from under you.

Which is why I use vscodium.

Noting that the point it not just avoiding telemetry, but actually having a tool as indispensable as your text editor not at the mercy of Microsoft whims.

Centralized control under any corporation, especially MS, is a different concern from the project "not being open source" which is what the comment I replied to was talking about.

But yes, it is a valid concern for sure.

It's better than using the MS builds but the SSH remote extension, python's new LSP ( Pylance ) and certainly few other plugins beside being close source don't even work with the open source builds of Vscode. ( + You don't have access to bunch of plugins if you don't manually edit your config to use Microsoft's store, which maybe against its licensing ).

If tomorrow Microsoft decided that some new versions of essential extensions should follow the same path VsCodium would basically become useless, I wouldn't trust Microsoft that easily.

Good points. I wasn't aware of these since my base VSCodium environment is quite minimal, but this definitely makes sense.

<disclaimer> After using Vim, VSCode and IDEs for many years, only recently have I tried to get seriously into Emacs. I use it for everything nowadays (from organisation to coding) with the exception of some very large Java projects where IntelliJ is definitely the best option for me.

org-mode was my "gateway". I always wanted to learn Lisp, so I guess that was a plus too (I'm aware Elisp is not the best way to learn it). </disclaimer>

I don't know if VSCode will be the new Emacs but I doubt it. It will be, and already is, hugely more popular, and I'm glad it is. I believe in people having a good choice of open source tools and using whatever they feel better using.

What I like about Emacs is that you are given vanilla editor and you have to make it "your own". Now some people like this, some people hate this. Some people like to quickly download a VSCode extension and just get on with it.

I also like how Emacs' "things" can have a synergy. I just recently setup my blog to be written in org with Jupyter-like code examples, pre-processing and exporting. This involves a few packages but they worked together nicely, It's all text after all.

I don't know how to do that in VSCode (parsing using an extension, processing the result using another, exporting with yet another, etc). Perhaps it's simple, but I guess that if you are doing this, then between VSCode and Emacs, they both require a reasonable amount of work.

Regarding speed I'm using Emacs 28 native and I feel it's a massive improvement.

Not sure what it would mean for VSCode to be the new Emacs. I assume it already has a larger user base and almost as rich a package ecosystem. The question for me is, will useful development of Emacs modes cease in the future? And will that energy be focused on VSCode instead? I think there’s a chance of that. But ultimately a lot of people who like Emacs don’t like VSCode. I personally think VSCode has chosen the wrong level of abstraction for the API it exposes to extensions, and I think its community doesn’t value UIs that are primarily text based. There are things in VSCode that I hate that can’t ever be fixed. That’s not true in Emacs. It’s always surprising to me when people complain about keybindings for example, when they have complete control over them. I’m also baffled by anyone who thinks VSCode has better documentation than what’s built into Emacs and each of its modes. I’ll be sad if I ever have to abandon it, anyway.

Try using VSCode in terminal mode when you're logged into a remote machine via SSH and see how well that goes.

> It's slow (I have i7 with 4 cores and 32Gb of RAM)

Something is wrong here. I can't remember the exact specs of the machine when I first started using it but it might have been as low as a 486 with 1 core and 32Mb of RAM.

That's because Emacs is web scale.

Yeah, the first machine I started using Emacs on was similarly spec'd, and it's only gotten faster since....

>>Try using VSCode in terminal mode when you're logged into a remote machine via SSH and see how well that goes.

On the other had vscode is the best experience I've had editing files remotely. Unlike emacs where you have install and configure tramp. The experience in vscode was seamless. In fact the Python vscode plugin is clever enough to understand you are opening a remote python project. It will ensure the local venv is set up with all your tooling(flake, black etc)

None of this possible with Emacs.

Emacs gives a good editing experience. But we have moved one from coding being merely a text typing excercise.

Data point: I've been using Emacs for about 5 hears. I've got a setup that works very well for me but every time I open my .emacs I hate Emacs lisp even more. Decided to give VSCode a go, my take is:

- It's really slow (noticable keyboard latency) and this bums me out.

- Haven't yet got into a proper VSCode git plugin but I'm pretty sure when I do I'll still miss Magit.

- The only place where I really miss Emacs' ultra flexibility is the window management. VSCode's model is pretty simplistic and seems dumb to me.

On the whole with my hatred of ELisp I think the relative inflexibility of VSCode is a wash, especially when you factor in how easy it was to get started. But it does make me sad to know if I stick with it I'll never escape the slowness.

What's wrong with elisp? I'm far from being a lisp fan, but as an extension language it seems perfectly adequate for emacs.

I feel the same. VSCode is better than Emacs in lots of aspects, but I cannot leave Emacs for now because Org Mode in Emacs is just too powerful. Although VSCode also has an Org Mode addon, it only has some basic functionalities and hasn't been updated for ages. Lots of people begin to create new products based on Markdown (e.g. foam, VSCode anki editor, etc.). But in my opinion, Markdown is not as great as Org Mode. For example, Org Mode can set properties for each heading, which is quite useful in some situations. I hope we can have more powerful Org Mode-related addons in VSCode.

Ultimately this comes down to the communities.

The Emacs community, although perhaps lacking the sheer number of vscode users, is incredible. There are folks like Henrik Lissner who are almost pathologically addicted to making Emacs awesome, not to mention the myriad other folks who escape my mind at the moment.

The vscode community is mostly full of valiant, short-lived one-person projects and things maintained by large companies. I must admit that for working with Azure, I do switch to vscode because the integration (e.g. for the ARM templates) is awesome.

Emacs has the better community for the long run (and has the track record to prove it), but I do wonder about the technical limitations of Emacs, mostly revolving around the quirkiness of elisp that Emacs is mostly married to at the moment. You can listen to Henrik discuss this here [0]. I experience some hickups when using Doom emacs, mostly when projects get big and the tooltip stuff has to render many options. Still, this is well worth it for the amazing benefits of Org mode, Org Roam, Org-ref, etc.

[0] https://www.youtube.com/watch?v=LKegZI9vWUU

(personal bias: i've been using emacs for about 20 years, though I don't know elisp and I have very mildly customized dotfiles)

I want to process and respond to this question, but I can't get past:

> It's slow (I have i7 with 4 cores and 32Gb of RAM)...

Consider that you must be doing something deeply wrong? I have a broadwell (2015) i7, 2 cores, 16GB of ram (8 of which is reserved), and Emacs is quite fast.

I tried to use VSCode once, around when it came out. It was a pathetic joke. Once you manage to stop laughing at the concept of using an editor, hosted in a webbrowser, written in javascript, you were able to enjoy exactly the performance you would expect from such an "application".

I couldn't type more than a few lines before the high latency, and the fact that I could feel my CPU heating up, gave me all the info I needed.

What's VSCode for?? I don't do much (any) UI work, so I'd believe you if that's its strength, but.. an editor???? I doubt it!

Having noticeable latency between keystrokes and requiring huge amounts of system resources make it kinda ... hard to take seriously.

personal bias: i've been using vscode for about 4 years

> I couldn't type more than a few lines before the high latency, and the fact that I could feel my CPU heating up, gave me all the info I needed.

Consider that you must be doing something deeply wrong? I have a MacBook Pro (2015) i7, 4 cores, 16GB of ram, and VS Code is quite fast.

I'll take that bet!

Keep in mind I said "when it came out". I don't know when that was, and maybe it's improved. A bit. That being said, the fact that VS Code isn't a native application, but something run as a local web app, is all the info you need. (no idea how it's gonna grab the keybindings it's gonna need if it's in a web browser... and the fact that it burns CPU on blinking the cursor isn't exactly a sign of Quality Engineering)

I would consider that, if it made sense to do so. But, my coding environments are pretty bare bones, there's not a lot of things to "do" wrong.

That being said, if I can do so in under a few minutes, I'll install VSCode right now and see if it runs... And if VSCode seems fast on your machine, you should check out emacs! ;)

As a fellow emacs user, I have to say that you're wrong and the "non-native apps are trash" attitude isn't super productive.

I do mostly backend development in a few languages, all using emacs, but will bust out VS Code when I need to browse a web codebase for whatever reason. It's a very performant application. It can grab all the keybinds it needs and my install with a handful of addons doesn't burn CPU doing nothing and is just as snappy as emacs.

Happy to discuss the pros of emacs but your cons list for VS Code is in part wildly outdated and in part flat out untrue.

> your cons list for VS Code is in part wildly outdated and in part flat out untrue.

What's untrue about it?

Not disagreeing with you, just am not in a position to test it myself (yet). I JUST managed to get VS Code installed, and am trying to run it for the first time, as I type this...

> ... bust out VS Code when I need to browse a web codebase for whatever reason.

Makes sense. I'll just go ahead and believe you on this, because I don't know what a "web codebase" is, how it might differ from a normal one, and hence benefit from whatever specialized tooling VS Code has for that. Does "web codebase" mean any interactive webapp, with HTML, JS, CSS, and some language or UI framework combined? I wouldn't be surprised if VS Code is superior out of the box for those sorts of things, if it's designed for them.

> It's a very performant application. It can grab all the keybinds it needs and my install with a handful of addons doesn't burn CPU doing nothing and is just as snappy as emacs.

We'll find out won't we! I now have VSCode running for a comparison. "just as snappy" is far from true, but I admit, it's far more responsive than when I tried it before. Possibly even usable.

I like the seamless integration of extensions! The need to "pick a folder" just to open and compile a single file seems a bit unnecessary, but a small annoyance. But I stand corrected, this is not nearly as bad as I expected. Once I can make it use emacs key bindings, and tweak it enough to have less "policy requirements" it might be worth a peek.

(Also an emacs user for 20 years and counting).

For the most part emacs is also not native: most of emacs is written in elisp, which only got a compiler very recently and it is very likely still nowhere as good as as the V8 jit.

I understand that as most electron applications VSCode was very slow and bloated initially, but these days people say is quite snappy (I wouldn't know, I never used it).

> And if VSCode seems fast on your machine, you should check out emacs! ;)

I did, I rely heavily on code completion, hinting, linting, marking unused variables, lighting big red light when I made type error... you get the point. And I have two conclusions. First is that setting all up how i like it was a pain, I finally had to use Doom Emacs as a boilerplate (kudos for hlissner, I believe this is best Emacs hope for new users), and it made it bearable, but whole setup felt really slow when UI had to take second or two before showing my precious type error.

Now, I really believe you when you are saying that i could make it faster. It's just that I would have to put evenings just to be basically in the same place.

Additionally, I would replace the most popular editor with one that has an almost negligible share of the "market".

The "it burns CPU on blinking the cursor" argument doesn't appeal to me at all, because it's not like the computer is unresponsive because that cursor is blinking, or even noticeably slower. I have to spend dozens of hours learning and configuring emacs to make parameters I don't notice improve?

> Once you manage to stop laughing at the concept of using an editor, hosted in a webbrowser

Webbrowsers are designed, as it's main function, to display text. Makes sense to me to use something that can render text in all sorts of different ways *as a text editor.*

I've tried to use Emacs several times, and come away thinking that it does a lot of things, but none of them particularly well. Elisp seems fine I suppose, but JavaScript is one of the most popular programming languages and so it's sensible to use that as a basis for an ide whereby more people have the existing knowledge to hack away with it.

I think so, but prepare for people to come out of the woodwork with all kinds of reasons why their workflow is the _one true way_.

Some people like customizing the heck out of their editor, getting super deep into metaprogramming and macros. Personally, I don't really have time for that. I want an editor which does 95% of what I want out of the box. For me, that's pycharm, but vscode is really nice as well. It feels lighter than pycharm.

You can usually configure all kinds of macros and plugins for IDEs. Like you said, it's a bit of a rabbit hole, but so is emacs lisp.

> Some people like customizing the heck out of their editor, getting super deep into metaprogramming and macros.

You will hopefully be programming for decades: I have been programming already for three decades and I expect I will be programming for another two before my mind gives out (if I am lucky, I might get another four). Customize your tools: they are yours, and being able to continue using and improving your workflow over time isn't a distraction if you are in this for the long haul.

If I work on different environments or desks, customization is the last thing I want. I would rather have sane defaults and start being productive immediately.

The same argument could be taken to the absurd by saying you only use notepad or nano because they're likely to be installed already so you can be immediately productive.

Even if the argument is taken to the absurd, the parent's approach can still be valid; if the user worked on an infinite number of environments (remember, this is the assumption of the parent poster), it'd be overall more productive to use barebone tools with zero learning overhead, rather than spending infinite time with the learning overhead of the infinite environments.

The core point is overall productivity; it may still be more productive overall not to know some tools extremely well.

A 20Kb .emacs file isn't that much to carry around.

> Customize your tools: they are yours, and being able to continue using and improving your workflow over time isn't a distraction if you are in this for the long haul.

I have programmed for 20 years professionally (and a few more). I have the exact opposite approach. I don't even learn ketyboard shortcuts, would never customize my environment even a little (like moving a tool window around in an IDE) because it just doesn't stick. The difference in philosophy is probably because I'm a windows dev and I just don't have (or trust) there to be a persistent settings storage. The small papercuts of not customization it is less annoying than the constant re-customization required when it keeps breaking, or you use a different machine. There is no real dotfile system, the user profile directory is a mess and even if it is, applications usually don't bother to maintain their settings and compatibility. So my philosophy has basically become: change nothing, and everything will look your way even on a clean system (and after the next upgrade).

I don't really believe in 10x programmers but I do believe in 1x programmers, and I do believe that many tool defaults conspire to make everyone a 0.1x programmer. Nothing works that great out of the box.

It might very well be, except the plugins are more difficult to write in VS Code.

On the joke side, Emacs also started out as a resource hungry beast, just like VS Code now.

Emacs feels to me a bit more extensible, and does a number of things better than VS Code (e.g., can cut rectangles, better shortcuts, regexp support, and others).

Emacs is my go-to when working on "lispy" projects such as Common Lisp, Scheme or Clojure. It's also my go-to for C/C++ projects.

VSCode has become my go-to for everything else.

As with most things it's not a question of emacs or VSCode, it's both - and the knowledge of when to use each.

I am almost in love with VSCode, but my workflow in never done 100% on it.

I usually start working on VSCode, but I run test from the terminal (python and solidity), and half of my git commits are from the command line.

When a test breaks, I usually use vim to fix it since I am already on the terminal.

I'd rather see Visual Studio 2022 for Linux than VSCode. The closest to that is Monodevelop https://www.monodevelop.com/

JetBrains Rider is a perfectly fine IDE that works on Linux. Way better and way more powerful than VSCode and Monodevelop. And in my opinion also better than Visual Studio (though I didn't try 2019 and 2022, Rider does everything I need).

Of course. VS Code is just a Chrome browser with a bunch of scripts bundled.

Where scripts includes anything you can compile to wasm. That enables a lot of interesting stuff. Including, say, compiling some lisp to wasm to e.g. retrofit some emacs stuff via a vs code extension. Probably a bit redundant but it would not surprise me to see some code sharing long term between the two ecosystems via wasm.

As far as I understand, VSCode extensions do not have the level of unfiltered low level access to the internals of the editor. In emacs there isn't really a difference between extensions and core features. It is just all code running in a lisp vm (and it is also the reason I'm sceptical about having other extension languages in emacs).

TL;DR It is already, for the good and for the bad.

probably the best thing that come from Microsoft in decades

update: has momentum, a huge marketing budget (helps) and the cost of entry way lower than emacs' one (typescript ecosystem a fair bit less exotic than lisps').

performance is OK, really. i remember more than 20yrs ago when one had to use vi, micro emacs and lesser options because emacs was then the resource hog. at same age / stage vscode is way less hungry than emacs then...

NO

Yes

I’ve wanted to switch to emacs for a long time, but it feels like a second or third class citizen on Windows. There are many guides online on how to prepare it to be used as an IDE for different programming languages but it all breaks down when you try to follow the guides on Windows.

On the other hand vscode is first class, or almost.

Funny, I feel like a second class citizen whenever I use windows.

What's wrong with using the official/native emacs binaries on Windows? My knowledge is at least a decade out of date, but the official build: http://mirror.rit.edu/gnu/emacs/windows/emacs-27/emacs-27.2-...

Seemed to work well.

The key is to get a shortcut to emacs in your SendTo menu :)

It works well, but online tutorials have instructions that don’t necessarily work on Windows. Some of the most popular plugins (or whatever you call them in Emacs) don’t work well on Windows either.

Ffs, can't people just use they editor they want and be happy with it? Does it always have to overcome and take over every other editor?

What the fuck does "the new emacs" mean?

VSCode is bloated by a whole web engine because Microsoft developers are too lazy to develop a proper editor from scratch.

Elisp is antisocial and restricting because Stallman fought against the use of modules and they only become available in with Emacs 25. As for FFI Emacs developers are still dragging their feet inspite of other developers an Emacs developer actually having done the work. All the core developers need to do is to integrate it.

As for question itself, yes VSCode can be the new Emacs if your workstations are powerful enough, Apple M1 Pro Max or whatever.