I wonder how many users Emacs has lost to VS Code over the past few years. I'm one of them.
Feels sad. And also potentially shortsighted.
Feels sad. And also potentially shortsighted.
I think Emacs users care more about the total population than one particular outmigration.
I don't have actual data, but if I compare to the amount of activity (blog posts, tweets/toots, packages, etc), then (heavy) Emacs usage seems to be monotonically increasing.
Almost everyone I know who switched to VSCode was using Emacs primarily for work, and mostly limited to SW development. That category of users may be large in absolute numbers, but most of the Emacs ecosystem is not driven by that category (i.e. even if that category shrinks to a tenth of its size, it won't have any impact on Emacs development).
Just take a look at the talks in the conference. The vast majority are orthogonal to SW development/programming.
Would someone not very carefully reading your comment think otherwise? Yes, probably.
Of course, how can you not love it? All the tools you need for writing are at your fingertips. You can have a thesaurus, spellchecking, translation and search, dictionaries, etymology lookup, word counter, Flesch-Kincaid reading ease tester, ChatGPT, Anthropic and other models, dictation, formatter, converter, exporter and so much more. Why would anyone ever exposed to that power willingly part with it?
- Thesaurus - there are a few different packages, powerthesaurus, le-thesaurus, etc. I use mw-thesaurus, at this point mainly out of habit, it's the first Emacs package I ever made and it served me so well, I never had reasons to look for alternatives.
- Spellchecking - I suppose flyspell still holds the majority, I prefer jinx.el, it completely replaced flyspell for me
- translation - also multiple choices, from translate-mode, org-translate, ob-translate, lingva, immersive-translate, etc. I use google-translate - for no particular good reason, it's just an old habit.
- search - consult-omni, it takes some initial tweaking, but then you can simultaneously search on Google, Wikipedia, YouTube, your browser history, etc., while typing the query once.
- dictionaries - sdcv
- etymology - define-it, wiktionary-bro
- word counter - is built-in; reading ease testing - writegood.el
- LLMs - multiple choices, gptel and chatgpt-shell are the most popular.
And to leave you with a practical recommendation, not just philosophical rambling, here's https://github.com/pprevos/emacs-writing-studio. Note that I haven't used it myself. I don't know anything about it, beyond its existence.
A significant portion of the Emacs "influencers" are not SW developers (think Protesilaos). Quite a few very popular Emacs packages are made by non-SW folks.
Which, as I pointed out, is why most of the talks are not related to SW development. Because that's not why the power users use Emacs.
In my (large) company, the bulk of Emacs users I've met use it for SW development, and little else. As such, while they may be really good users for the SW development they do, they tend to be fairly ignorant about the rest of Emacs (not heard of org mode or magit, some even think XEmacs is the improved Emacs, etc). Globally, such folks may well be in the majority, and if the bulk of them stop using Emacs, no one would even notice.
In fact, as someone who's been using Emacs since before VSCode existed, I simply did not notice the (real) exodus to VSCode. If you follow only the Emacs ecosystem (Emacs reddit, blogs, social media), the online engagement has exploded in the last 15 years. You would never guess that Emacs may have lost users overall (if it did).
Not a goal in itself to capture everyone, of course. But it's a data point!
Emacs proceeds strategically, not tactically. Even though it outlived so many different editors it was only a single decade, a point in history when it was considered kinda, sorta mainstream, the rest of its lifetime it wasn't.
Emacs is just like Lisp itself - it never dies, and never gets to be hugely popular. Anyone wishing either speedy death or widespread popularity for Lisp (and Emacs) will likely remain disappointed. Those who value Lisp and Emacs will continue using them, even decades from now. Those who never learn to appreciate either - will keep ignoring them.
There's nothing wrong with looking at the ecosystem and saying "huh, this is a pretty good idea". Emacs (the community as a whole) didn't ignore the LSP, and thanks to that it gets first-class support for tools that otherwise would have required someone to show up and "do the work" to get it to happen.
I do think we're in agreement about "strategically, not tactically". Like Emacs _is_ doing its own thing. It's just that sometimes you can see good ideas from other places.
The only rule it insists on is the parentheses, and it's quite ridiculous how people dismiss the entirety of this foundation for incredibly powerful ideas and abstractions, solely for that reason.
I don’t even think VSC is “that” bad despite what I made it sound like, but it’s probably as temporary as any other modern IDE. In a few years “every” VSC user will probably have moved on to Zed. Meanwhile your emacs (or vim) dot files will setup the only IDE you’ve ever used on any machine.
In VS Code I use the "Awesome Emacs Keymap" extension by Yuichiro Tachibana (Tsuchiya):
https://marketplace.visualstudio.com/items?itemName=tuttieee...
What won me over? GH Copilot + the overall packaging. It just works. Good, polished UX. Emacs needs to catch up on this front.
A quick google search got me vscode-dired (incase anyone else runs into it):
https://marketplace.visualstudio.com/items?itemName=rrudi.vs...
Quick Tip: I set C-x C-d, C-x C-b and C-xb all to call extension.dired.open per this stackoverflow: https://stackoverflow.com/questions/62235792/how-to-add-mult...
that seems to satisfy the muscle memory... and it seems at first glance that this time the switch to vscode might actually stick. (thanks for the link to the emacs keymap extension)
We'll see how it goes!
edit: After even 5 minutes of building some rust code I ran into too many issues! I love the syntax highlighting in VS Code and everything else but I have way too much custom elisp to build and debug Rust/Go/C++ and recreating all that in VSCode or learning the new bindings is a bridge too far! I would pay real money to someone who would build an amazing performant experience for emacs. Sigh.
* except RustRover but that comes with its own set of issues
What kind of emacs scripts do you write to help debug Rust?
Then I have a bunch of elisp code that calls just and / or generates boilerplate code right in the buffer - M-x new-macro or M-x run-test (asks for a test to run) etc. I keep writing more elisp as I go along and add specific key bindings to specific things and now its too hard to move away from it all.
Have you tried https://github.com/blahgeek/emacs-lsp-booster? Also, build Emacs --with-native-comp flag
That "it just works" thing gets me all the time. I just don't get it. Some things surely do work nicely out of the box in a proprietary specialized tool, like for example JS/TS-related things indeed are very nice in VSCode. Just like Java-related stuff works great in IntelliJ.
But programming is far more than writing code. I can argue that writing in plain English for a programmer is perhaps far more important than writing in a PL.
And for any kind of plain-text manipulation, Emacs absolutely has no match today. Of that, I'm certain, because I have watched and followed many VSCode/IntelliJ power users and long-time users, and I do occasionally use those tools personally as well. There are so many practical example use cases where Emacs just kicks things out of the ballpark - from sending requests to LLMs in the midst of taking notes, to controlling video playback, and annotating PDFs - typing those annotations while browsing the document.
And then that "it just works" fallacy. No cookie-cutter solution ever can make a true coder happy. How can one not get annoyed by a bunch of minor, seemingly not-big-of-a-deal issues over a long period of time? Like having to use the mouse for certain operations without a good alternative, or fixed keybindings that can't be fully customized, or the search bar not remembering your last search position and parameters? It's like buying a car with seats at a fixed angle and not even being able to change that.
I mean, sure, Emacs may seem dauntingly complex at first glance, but the initial investment in learning this infinitely hackable tool pales in comparison to the countless hours lost wrestling with the unchangeable constraints of less adaptable alternatives.
> I tolerated the LISP aspect.
I don't know the extent of what you meant by that, but I guess you've "acquired a vehicle," using it to commute and go grocery shopping, and never even realized that you had an actual spaceship all this time. Emacs is most importantly "a Lisp Machine" with a built-in text editor and not the other way around. It is exactly Lisp that makes it so fascinatingly hackable. One chooses Emacs, Lem, Light Table, etc., specifically because of Lisp, not to "tolerate" or "suffer" through dealing with it.
Still use emacs + org mode for notes though, and spent quite a lot of time getting VSC to act like emacs in terms of shortcuts etc.
Sounds like you didn't switch, but rather added another tool in your toolbox.
The constant comparisons to VSCode frustrate me because they're often presented as "either-or".
I use Emacs. And I use VSCode.
I can say the same for Vim... My primary editor is Emacs, but I use vim if I want to edit something quickly in the terminal (config files, git commits, etc). If the codebase is bigger then I use the JetBrains IDEs...
I installed VSCode but I just don't like it. Until today I didn't find a use case for it being added to toolbelt. But I must admit that it almost won the editor wars, people just suppose that you use it.
I switched in late 2015, things were different back then. If it was today I think I would probably jump to Doom Emacs or Neovim.
What?
> the plugins are ass > the LSPs are horrible for basically anything which isn’t Typescript
What??
I need to edit projects on a remote machine nearly every day. (I do cross-platform Python dev so I need to run and test code on Windows and Linux VMs while working on a Mac.) Compare VSC’s Remote Edit plugin to TRAMP and let me know what you think. For me it’s not even a contest. TRAMP just simply doesn’t work in a majority of use cases and I’ve only had a few small hiccups with the VSC Remote Edit. Getting LSP plugins working over TRAMP on another machine is hell. I just use Emacs for org-mode and Magit now.
[Yeah, yeah, I know, I shouldn't be running NixOS and I should use a Microsoft (c) approved OS instead like all the cool kids. Wake me up in 100 years when Microsoft ceases to exist.]
Also, the emacs approach uses very little resources. This matters if your LSP server takes 80% of your RAM. Vscode takes 20%, emacs/tramp doesn't.
You would have to compare what VSCode does to running Emacs server side and connecting with Emacs client to the server. Then it would be a fair comparison.
Maybe you don't have to use VS Code full-time, but having a knowledge of it is useful.
Personally, I started using VS Code because support for frontend is much better there than in JetBrains IDEs and it has great remote editing capabilities. I would prefer to use JetBrains IDEs (I did for many years, and I still go back for Java), but VS Code is just better. I would never use Vim for editing full-time, though I do use lunarvim when I need to quickly edit a remote file.
I am not sure how the speed of both compares, if one properly sets up Emacs on the server as well, to make it a fair comparison.
It depends on so many different things. Aside from platform specifics (sure, it can be painfully slow on Windows), Emacs might feel slow for various reasons, but it doesn't have to be. Built-in Profiling tools are godsend and if used properly Emacs can be quite impressively fast. My Emacs starts quickly (in less than a second), and it is very pleasantly snappy.
I don't think there's an argument to be made that we're at risk of losing something. So much of editor progress in the past ~years is shared -- treesitter, lsp backends, linters and snippets, etc. It's hard for me to imagine how the editor ecosystem could collapse.
Another example: grep in the current project for any function matching foo bar baz in any order followed by an open paren, restrict the search to only header files, export to a buffer, run search in replace in that temporary buffer, review the changes, then commit the modification to disk in every matched file with a single keystroke.
https://github.com/minad/consult/
> And also potentially shortsighted.
Looking at the recent releases, it feels like the vscode enshittification has already begun...
a) lack of regular revenue leading to bizarre product management choices (probably not a case, because of GH Copilot subs)
b) initial really talented team members gradually being replaced by bozos because of entropy and/or management (work on something new/important)
I suppose b) is the most obvious risk.
On top of that they get some wild telemetry. Your privacy data is obviously safe, but the metadata they collect goes right down to your project structure. So Microsoft knows what sort of projects and in what sort of languages everyone uses. They know what you’re putting into your Azure cloud and they know if you’re not using Azure. I imagine these things are rather valuable to the biggest tech company in the world.
Obviously they’re going to focus their development on upselling Microsoft products to you. Which will only get worse as they succeed more and more. Because why wouldn’t an enterprise company do that?
I understand why people like VSC, but at the same time I’ve seen people go from other IDEs to VSC and now many are going yo Zed. Mean while I can just trundle along in the same IDE. Some of the emacs purists haven’t had to learn a new IDE for decades and likely never will.
To each their own of course.
Alarmingly, basic proficiency in VSCode becoming a must in many software developing teams and I don't like that. People really seem to have zero concerns about Microsoft aggressively pushing their proprietary agenda, neatly wrapped in "open-source" packaging.