Hacker News Reader

Comment by dleslie | Hacker News Reader

It's weird to be building an Emacs clone nowadays. It's fairly clear that Vim and Emacs _both_ lost the editor wars, and VSCode has come out on top. That's not to say either Vim or Emacs are dead or will disappear, but building a clone of a niche editor is risking dooming the project to being a niche within a niche.

If it's just because hacking is fun, then by all means have a blast. But if the goal is to compete with Emacs, consider instead setting the target at something with far greater popularity than Emacs.

View on HN

Speaking from personal experience, I moved from VSCode to Doom Emacs a year ago, and the on-ramp wasn't nearly long or as tough as I thought. The defaults are good, and anything else that I customized I actually just used ChatGPT/GPT-4 to generate it. It took about a month to get used to the new setup. With LSP/Magit, it feels like I'm not missing out on much from what VSCode offered, and then whenever I want to personalize it, I can. For a creative person (which I'd argue most developers are, kind of by definition), it's fun.

I've been using Emacs for roughly three decades; it's my favourite editor. And for sure, LSP has been an absolute game changer.

Worth noting is that LSP came from Microsoft as part of their efforts to build a better editor experience; and its integration with VSCode is largely unparalleled.

For example: in VSCode the user doesn't have to understand how to install a language server, it just automagically suggests allowing it to install one for you. In Emacs, if you're using the official distribution you will have eglot, whose developers specifically refuse to add that functionality. If you're savvy enough you can install lsp-mode and it will add that functionality, but at that point you may as well just install the language server yourself.

And about magit: it's a beautiful piece of software, it truly is. It's also hot garbage with large repositories hosted on Windows. I simply cannot use it for work because every operation takes around a minute to resolve, which locks up Emacs entirely. Again, here VSCode shines because the default git integration is pretty good, and there are extensions that make it excellent.

For these reasons, and more, I always recommend VSCode to new developers and don't recommend Emacs. Emacs is for people who want to make editor customization a _hobby_.

>For example: in VSCode the user doesn't have to understand how to install a language server, it just automagically suggests allowing it to install one for you. In Emacs, if you're using the official distribution you will have eglot, whose developers specifically refuse to add that functionality.

I can understand this not being friendly for some users, but on most systems that people are using Emacs on, software is installed through a system package manager and not downloaded and unpacked into ${HOME}. I do not want software that isn't the system package manager to install LSP servers.

Maybe this is more of an issue for people using Emacs on Windows, since there is no system package manager, and people are less likely to understand how to install stuff.

"savvy enough" for emacs these days for lsp is literally "M-x package-install lsp-mode"

Earlier today I started up emacs in a C++ project after working exclusively in Rust, and I didn't have an lsp server for C++ installed. I did M-x lsp-mode and it prompted me (paraphrased): No language server for C++ installed, do you want me to go get one for you? Options are: clangd. Sure, said I, and it just went and installed it and off I went.

Granted, you'll also need company-mode and stuff, yes. And to get an IDE like experience... treemacs, projectile, etc. etc.

Yes, it's an acquired taste. But it's not like it's obsolete. It's better and more active than it's ever been. And I've been using Emacs (mostly casually) since 1992.

I was gonna mention that installing lsp-mode is as easy as clicking 'Options->Manage Emacs Packages', scrolling down to lsp-mode, clicking it, and clicking 'Install', however it turns out lsp-mode isn't in GNU or NonGNU Elpa, so it requires setting up MELPA first. So unfortunately it isn't entirely tech journalist friendly.

First you have to know that lsp-mode exists. VSCode just detects what to do from the file.

About projectile: Emacs ships with project.el and that does 90% of what projectile can do.

I'm sorry maybe this has improved in the two years since I tried but the last time I tried to set up VSCode to even approach the capabilities of CLion (the tool I used most at the time) it required a whole bunch of configuration, and stuff that felt more brittle and confusing than the emacs setup I have now.

In particular, no, it did not do all the LSP stuff out of the box, and didn't do basic refactorings out of the box either. Maybe it does so for other languages? Or maybe they've fixed the UX? But I recall having to install at least two or three plugins. And along the way found some that fought with each other.

I have never used VSCode for C/C++, only Emacs and Visual Studio, so I can't comment on how it compares to CLion. VSCode and C#, however, is something I prefer to Visual Studio or even Rider.

> Emacs is for people who want to make editor customization a _hobby_.

I disagree. I use it for org mode to take notes, track time, and write documentation. I use it with SLIME to program in Common Lisp (side projects, though). I make changes to .emacs or write an elisp function once in a while, usually to finesse something that I do frequently, but it's definitely not a hobby. It's a great tool, even before any customizations, IMO.

I've also been using Emacs for 3 decades. Although I could probably be happy with vscode for coding, neither vscode nor any other app I am aware of is a satisfactory substitute for Emacs as a personal information manager (PIM) because neither vscode nor any other app can be modified easily enough. (Apparently, I care whether my PIM supports my personal way of working more than I care whether my code editor or IDE does.)

Maybe if I were a professional web developer, I would be able to modify vscode in the ways I feel it needs to be modified to support my personal style after a reasonable investment in learning vscode internals, but that is manifestly not actually the case.

BTW, I don't use and don't like org mode.

I'm pretty sure I read this exact comment 10 years ago, but "Sublime Text" instead of "VSCode".

And Atom, as well.

I suppose TextMate was a bit more niche, being OS X only, but at one point it seemed to be everywhere.

Hmm, while we're counting, what about BRIEF? At one point, widely enough used that Visual Studio even had BRIEF emulation!

(When I was starting out in software development, almost all of my colleagues used this. Now just a footnote.)

BRIEF by UnderWare! I loved that editor. I particularly liked the “go to this line number, but use the line number before unsaved edits”. This let you compile a file, get the error log, then start making edits; but the line numbers in the error log were still useful.

https://en.wikipedia.org/wiki/Brief_(text_editor)

VSCode is why Sublime Text, Atom, and others are not as relevant as they once were.

And in 10 years, there will be a comment saying "XYZ is why VSCode is not as relevant as it once was."

And Emacs will still be around.

And VSCode will still be around.

Atom is not around. Not 100 percent sure that VSCode will be around. (But I also don’t think that this should hold anyone back who finds VSCode to fit their needs best. There’ll be something else that will take its place.)

Just as Sublime Text is still around :-)

My impression is that all of those are fads, we jsut haven't seen VS Code fade way yet, like the others have. I've used Emacs throughout all of those fads, seems easier than switching editors every few years.

> It's fairly clear that Vim and Emacs _both_ lost the editor wars, and VSCode has come out on top.

Many (most?) Emacs enthusiasts don't use it primarily for SW development. VSCode simply isn't an alternative for their needs.

Make two lists:

- List of things you can do in VSCode that you can't in Emacs

- List of things you can do in Emacs that you can't in VSCode

The latter list will be 10-100x longer.

"The latter list will be 10-100x longer."

And on top of all that the actual core editor is, once you get your fingers wrapped around it, just... the best. It can do so many things that other editors just don't do, it's responsive and fast, the buffer metaphor it works with is great (so easy to have the same file open in multiple windows at different regions, it's beautiful) and I love the tiling system for its frames, etc. etc.

In 30 years, we'll still be using Emacs, but VSCode will have moved on.

Since I only use VSCode (or Codium...), what sorts of things would be in the latter list?

Can I use VSCode to:

- Read and reply to my emails?

- Manage TODOs across domains (so e.g. I can make a TODO that has a link to a specific email)?

- Use it as a Mastodon client (read and write toots, boost them, favorite them, etc)

- Scrape a web site (several pages), getting only the relevant content[1]

- Bulk rename/copy lots of files with a custom naming algorithm

- Chat on IRC

- Use it as a spreadsheet

- Do numerical integration with it

- Have a literate document with code in several languages that talk to one another

- Annotate PDFs

This is a tiny list. In fact, you can browse past Emacsconf talks to see how people use it.

[1] https://blog.nawaz.org/posts/2023/Mar/solving-a-scraping-pro...

I think it's fair to say that most people don't need, or even want, their IDE/text editor to do a bunch of stuff that can be done with other programs. I know Emacs people like it (I was, at one time, an Emacs person), and that's great, but "can your text editor/IDE do a bunch of not-text-editor-slash-IDE stuff?" is a weird gotcha. Sometimes you want to buy your dessert topping and floor wax in separate cans, y'know?

Emacs is the can class, not two can instances. The power comes from a single can interface, and leveraging one's can-fu across multiple tasks. Also, everyone enjoys some foot cheese in their whipped cream.

Most people don't need or want all the UNIX tools' capabilities. Does it make sense to compare the Windows command environment with the Linux one and say "Don't include all these capabilities in the analysis?"

> but "can your text editor/IDE do a bunch of not-text-editor-slash-IDE stuff?" is a weird gotcha.

It's not a weird gotcha when dismissing the tool. If you want to artificially narrow the comparison to "writing SW" (which is even narrower than text editing), then by all means - VSCode is the superior tool. But why stop there? The bulk of PC/laptop users use Notepad as their editor, and have no use for VSCode's capabilities. Shall we dismiss all the cool things in VSCode for it?

And sorry, what? Non-editor stuff? About half the items I listed are editor related.

> Sometimes you want to buy your dessert topping and floor wax in separate cans, y'know?

True, but wouldn't it be at least nice if you could buy both cans from the same store, using the same currency?

No one's arguing using only one tool. As I write this, I have both VSCode and Emacs windows open. Use the tool for its strengths. But blanket comparing VSCode with Emacs is silly - it's like comparing Excel with all of Linux. One is an application. The other is a platform. Excel is easily the best spreadsheet out there, but for many people, Linux is much more useful than Excel.

> It's not a weird gotcha when dismissing the tool. If you want to artificially narrow the comparison to "writing SW" (which is even narrower than text editing), then by all means - VSCode is the superior tool. But why stop there?

One, I wouldn't have conceded the crown to VSCode so easily as that. A fine-tuned Emacs config, with the requisite muscle memory and custom elisp, is a hot rod. I do use VSCode, and before that Sublime, but it was under protest, the details don't matter here but there were features I needed and no task budget for provisioning them in Emacs.

Second, why not stop there? I have a program for reading my email, it isn't VSCode, I'm fine with that. So telling me Emacs can read email is completely irrelevant to my use of VSCode. For most people, adding all of these features to the Emacs side of the balance backfires, because now Emacs has to be better than all the tools they use for that stuff, rather than just better at what VSCode does than VSCode is.

"Emacs does everything" is an aesthetic, and it has many decades of refinement, and people like it. That's fine.

> Most people don't need or want all the UNIX tools' capabilities. Does it make sense to compare the Windows command environment with the Linux one and say "Don't include all these capabilities in the analysis?"

This isn't at all what you're doing. It's more like if someone says "awk is fine for text munging, why would I use Perl" and your answer was that Perl has a web server.

There's such a thing as a like-for-like comparison. Emacs has org-mode, it has SLIME, it has paredit and parinfer. Those are all edges over VSCode, whereas checking email isn't. This conversation piqued my curiousity, and indeed, there's a plugin for that[0], a few actually, and yes, I'm sure Emacs does a better job, for some value of better. But I'll never know, because I don't intend to use either tool for that job.

[0]: https://github.com/buhe/vscode-mail

The reason some people, including myself, like to do things like email or irc or whatever inside emacs is because we got hooked on the powerful text and buffer management facilities in emacs, and want them everywhere, and consistently.

All these things we're talking include editors in their separate applications. They just use the default OS editor widget using CUA bindings or whatever. Pulling them into emacs turns that on its head, and brings with it all the power (and weirdness) that comes with that.

It's not for everyone, but it's also not something that it's fair to make fun of or dismiss outright.

In the end, what the emacs nerds are doing is remaking the world of Lisp machines, but compromised and/or modified for the environments we have now. Not everyone digs that. I kind of do.

Just that something is largely written in Lisp, doesn't make it a "Lisp Machine", nor a clone of it.

> but compromised and/or modified for the environments we have now.

I would think that GNU Emacs is also compromised by its own design decisions, starting in 1984, when RMS rewrote Gosling Emacs.

> not something that it's fair to make fun of or dismiss outright

I took pains not to do that in either post I made.

> Second, why not stop there? I have a program for reading my email, it isn't VSCode, I'm fine with that. So telling me Emacs can read email is completely irrelevant to my use of VSCode.

I agree it is irrelevant to your use of VSCode. The comparison, though, was for VSCode with Emacs. Not "VSCode with Emacs for samatman's needs".

> For most people, adding all of these features to the Emacs side of the balance backfires, because now Emacs has to be better than all the tools they use for that stuff, rather than just better at what VSCode does than VSCode is.

It's illogical to say that Emacs has to be better than all those tools to use them. We're not enforcing a dichotomy. You can use both. You can use Gmail's web interface and Emacs mailing abilities. All you need is for one to have some capability that the other doesn't, as opposed to having every capability the other has.

Next: A large part of my point in this thread is that comparing VSCode to Emacs as a whole is in itself silly - one is a fairly specialized tool and the other is fairly generic. If you want to reduce the discussion to SW development, then fine. But people (not you) blanket saying VSCode is better (or worse) than Emacs is like saying Excel is better than Linux. I don't have any desire to convince someone to leave VSCode for Emacs. What for?

Next: Implicit in your comments is the notion that stuff like reading mails is an "extra" in Emacs. It's artificially categorizing. Reading email in Emacs is not an addon - it's part of Emacs's capabilities (although you may get better experiences than the default with addons). If reading/writing emails is considered "extras", then keep in mind so are things like syntax highlighting, debugging, compiling, etc. Emacs is a text editor, and all those features are addons - at the same level as reading mails.

As a VSCode user, some of these addons mean more to you, and you don't care about the others, but understand that lots of people do care about them. So many people out there use Emacs only for org mode and magit.

> This isn't at all what you're doing. It's more like if someone says "awk is fine for text munging, why would I use Perl" and your answer was that Perl has a web server.

Context matters. Understand that my list was in response to "What can Emacs do that VS Code can't?" If someone asked "What can Perl do that awk can't?" then mentioning CPAN and Web servers is totally appropriate. It's pointing out that if you learn Perl, it may benefit you far more than awk ever could. Whether it would or not depends on your goals, of course.

> There's such a thing as a like-for-like comparison.

Agreed, but it helps if the scope is stated clearly. More often it's "Why do you use Emacs when VSCode exists?" And then of course, I'll list all the things I do in Emacs that VSCode doesn't provide. If someone asks "Why do you shop at Walmart when you can shop at Whole Foods?" it's not a problem to respond with "Because I can buy electronics at Walmart." You wouldn't jump on him and say "Hey, you're not doing a like-for-like comparison!"

While I, an inveterate emacs user, largely agree, you're not going to change any minds when the debate topic is "Vim and emacs both lost to vscode in the editor wars." To nearly everyone reading this thread, the bulk of whom are under 35, emacs is just a programmer's editor, and will be judged on its program editing.

If emails is considered extra, then so are things like syntax highlighting, debugging, compiling, etc.

Yeah no. The first is email, the latter three are directly relevant to program editing.

> you're not going to change any minds

I am repeatedly accused of this. Consider what I have written:

> then by all means - VSCode is the superior tool.

> No one's arguing using only one tool.

> As I write this, I have both VSCode and Emacs windows open.

> We're not enforcing a dichotomy. You can use both.

> I don't have any desire to convince someone to leave VSCode for Emacs. What for?

I certainly won't change any minds, because I'm not trying to.

> To nearly everyone reading this thread, the bulk of whom are under 35, emacs is just a programmer's editor, and will be judged on its program editing.

While I can agree they are the majority, this is a strange take. Do HN readers come to the site to reinforce their problematic views?

And do you think Emacs submissions often hit the front page because those upvoting view Emacs as "just a programmer's editor"? Quite a lot of these top voted submissions (the majority?) are not about programming.

> Yeah no. The first is email, the latter three are directly relevant to program editing.

You are welcome to whatever hierarchy you wish. From an objective architectural standpoint, all are extras on equal footing. I suppose perhaps some of these may have extended support in the C code, but otherwise they are just elisp libraries on top of the core.

TIL about mastodon.el and now I'm off to MELPA that hot stuff.

I don't think there's anything that's technically not-doable in VS Code that emacs can do. For me, it's more about ease of use that differentiates the two. Specifically around extensions.

https://code.visualstudio.com/api/get-started/your-first-ext...

That's the VS Code description on how to start writing extensions to VS Code. The first steps involve installing node.js so you can install another tool so you can generate scaffolding.

In emacs it would be:

Step 1: Open emacs

Step 2: Open a scratch buffer (q&d extensions, put in a .el file if you want to preserve it)

Step 3: Write some lisp code

Step 4: Evaluate the lisp code

Step 5: There is no step 5, use your extension

Caveats:

You have to learn programming to extend either of them so that's a common burden.

You have to learn lisp to extend emacs, but that's an easy thing to do.

You have to read the documentation to really get going with extension development, another common burden.

Apologies if this is do-able in VSCode, but for me the killer feature of Emacs is that configuration is literally just running code.

In VSCode, I don't think there's anything like "place code in this file, run it at startup, and code within this file can be present/applicable everywhere". Maybe you could do something as a plugin, but that is a big lift compared to Emacs.

For example, think about doing a "Hello World".

In Emacs, you just open init.el and place `(message "Hello World!")`.

In VSCode, you have to follow a whole set up for an extension [0].

[0]: https://code.visualstudio.com/api/get-started/your-first-ext...

This is the best thing about it for me as well. You can experiment with M-: or the scratch buffer to figure out what exact bit of elisp needs to be invoked; then use defun in the scratch buffer to make an interactive function of it; then use M-x or a keyboard macro to test it repeatedly while you're fiddling around; then assign a shortcut and test that out too. Once you're done, you've got everything in the scratch buffer and/or M-: history to paste into your init.el. Worst case, you'll mess up your startup file and need maybe 2 or 3 restarts total to ensure that you've captured everything correctly.

If you can do this in Visual Studio Code, it was not at all obvious how when I was looking. There's seemingly no way for you to add any code that executes in the editor's VM without literally restarting the process with your updated code in place. (Visual Studio suffers from a very similar problem.) 2 or 3 restarts is just the beginning! You'll need that many just to be sure you've got all the boilerplate in place.

Check out org mode (very complex and advanced task management / todo list system, calendar, etc), org roam (basically all the features of Obsidian), the ability to act as an email client, having a cross platform system shell independent shell (in elisp), and of course just general emacs architecture things like the ability to hot reload and replace and debug and inspect and get docs on and add to and modify every part of the editor

> lost the editor wars

What does that even mean? Both editors have large&strong communities. I don't see them going anywhere.

Software definitely doesn't have to be popular to be useful. Not being extremely popular comes with advantages as well. Nevertheless, Emacs is probably more popular than a lot software shared on Hacker News.

If someone is interested in lisp, you can assume they aren't driven by mass market popularity. Why on earth would want to go up against MS on their turf???

I, for example, am very happy that the Helix editor exists, which could be considered a clone of Vim (if you squint a little).

I'm pretty sure the authors of NeoVim heard wise advice like yours, but I'm happy they continued.

emacs and vim were niche way before VScode was around. The goal was never market dominance. It's not a market. It's a tool. With users. And these users are also active contributors to their own ecosystem.

Diversity of interest does not equate to intensity of interest.

Why do anything if there is already someone doing it?

> Vim and Emacs _both_ lost the editor wars, and VSCode has come out on top

I dream about a day when programmers stop being fervent zealots about tools they use and instead try to find pros and cons of their tools and try to borrow good ideas from each other.

This 'Emacs vs. Vim vs. VSCode, etc. etc.' comes from poor understanding the core principles of each of these things.

Can we discuss these things without emotional attachment, or even forget for a minute that they are "editors". Instead of trying to find who's wining "the editor wars" (is it even a thing?), can we instead talk about the big ideas behind them?

- What makes Emacs so powerful for many, and at the same time so intolerable by many others? The big idea behind Emacs is Lisp. Without understanding the core principles of Lisp, and by "understanding" I mean truly experiencing the dynamic nature of it, its malleability, the structural editing, 'true REPL', 'code is data', etc., it is quite pointless to even start such a discourse.

Lisp is amazing. I firmly believe that every programmer should gain good familiarity with Lisp. I am forever indebted to my younger self for forcing myself to learn Emacs and Emacs Lisp and for discovering the beauty of it. Learning Lisp made me a better programmer. I'm not claiming to be a good programmer today, but I was much worse before I learned Lisp. Lisp helped me understand FP, composability, meta-programming, logic, recursion, lambda calculus, symbolic computation, generative testing, and even type theory. And I'm quite sure, many other programmers can share the same sentiment.

- Without understanding, I mean not just "understanding", but heartfelt use of it for many months and maybe even years of the fantastic, remarkable idea behind modality and mnemonics of Vim, it is quite impossible to explain what makes it irreplaceable for those who learned its power. And by the way, there's no such thing as vim-mode. No other editor or IDE truly was able to recreate that model, with one exception - Emacs. None of the IDEs - IntelliJ, VSCode, XCode, Android Studio, etc., can properly emulate Vim-navigation. Only Emacs does a better way of vimming. Pretty much every other IDE fails to replicate Vim. Unless it's Vim/Neovim, vim-mode in all of them is just that - an emulation. However, Evil mode in Emacs feels much more natural. Sometimes, you forget that it's an afterthought, an extension, and not a built-in functionality. And that's due to the power of Lisp. Also, these days, there's ton of interesting stuff getting build on top of Neovim, because now you can use Lua instead of vimscript. And with Fennel - a Lisp that compiles to Lua, one can build some really interesting extensions.

- Now, VSCode fancies the idea of being built on top of a web browser engine. Turns out, it ain't such a bad idea after all. Perhaps Vim and Emacs should also one day try to have their own, built-in web browsers. I mean truly built-in, so one can extend it and change it and build things on top of it.

I guess, it turns out there's no such thing as "editor wars". VSCode is more popular today because certain ideas behind it make it appealing for many people. For the same reason, certain ideas make Vim and Emacs more appealing for others.

I need an editor that starts up, cache cold, in a few hundred milliseconds at most. Thanks for playing.

To be fair, that's not emacs. I'm a huge emacs fan, but its startup is awful compared to vim & friends.

Yes, you can use emacsclient, but that's a bit of a different thing and has its own disadvantages.

My Emacs is full of extra bits and pieces, and it cold starts on a Pinebook Pro in 6 seconds. That said, I still run an Emacs daemon and use Emacs clients, which start up in milliseconds.

I mean, mine's about the same startup, but that's ... like a hundred times worse than a Vim startup.

Well, Lem starts very fast, but more like 1 second or a little longer. It is very snappy to use also.

This post MUST be pure irony. Big lol! Thanks for the fun.

Reply on news.ycombinator.com