I have realized recently that a value that is gaining a lot of importance for me is the stability of my cognitive investments, in terms of tooling, across a time frame that goes beyond my "current project", and more into the "my entire career" territory. In that sense, I feel more and more that the choice of learning and owning Emacs, more than 20 years ago, while in school, has paid off tremendously, in the sense that it has always constituted a solid and consistent backbone from which I can always start a new project, no matter what the context is (corporate or personal). I feel this would have been harder to achieve with a tool which is asking me to update it every 3 days, and which periodically introduce important paradigm changes forcing me to reconsider the way I work. In short, I value Emacs' stability and consistency across time and tech fashions more than anything else, as I grow older.
This is the reason I left the whole app ecosystem. Apps are cool, and sometimes really great, but there’s no sense of permanence, no guarantee that your data will survive for long, that the app will be maintained, or that future devices will be able to run the app or access the data.
That sounds good in theory. But if you're working with a more-than-30-year-old tool, you're either:
1. Missing out on "new innovations" (and using older gui/etc paradigms which don't mesh with anything else you are used to).
2. Finding ways to update your tool to take advantage of "new innovations", which costs time, and often gives you a worse outcome.
I was a vim user for 8 years, then used spacemacs for another 2, but have lately switched to VSCode (with vim mode, obviously). The ease of just downloading vscode and having it work with almost no tinkering, having it look good, and being able to, for the most part, double-click an extension name if I need it... that ease of use means that whatever learning curve I do have to pay sometimes, it's worth it.
(And the learning curve for making VSCode have the vim/emacs features I need was tiny compared to managing my vim/emacs config).
What is more innovative, a light IDE with plugins written in JavaScript and backed by a big company or a small Lisp machine disguised as a text editor where every key is bound to a Lisp command and every changes and extensions in its code or extensions can be tested interactively in a "live coding" environment, where the user is empowered to modify and extend what he wants?
I think the way vscode is currently managed, it won't hold up to time if the trend continues. A competitor that strips the baggage might just kill it, even if there is a lot of user content by then.
Vim and Emacs are console editors for me. The most significant difference for me is sensible mouse support. I used Emacs just for LaTeX, otherwise I use mostly unhacked vim. It is very useful to be familiar with one of them, but nano is awesome too and I always mention it for new developers.
I believe vscode is successful because it is simple. Just like how JSON was successful compared to XML for simple applications. It isn't better than XML, but most applications are too simple to warrant XML features and resulting complexity.
For C# I prefer VS instead of vscode and I fear vscode tries to be both, a code editor with extended features vs a fully integrated IDE. For some language like JS vscode already has become an IDE with advantages and disadvantages and it is quite often very opinionated here.
i was looking into vscode/vscodium recently (i'm emacs user, but arguably more comfortable in javascript than emacs lisp). if you want to define a custom function do you have to write your extension? it seems like settings.json, is just that, a json file, as opposed to emacs config where you can drop a line into your config or even just eval some elisp in a buffer and have it modify your editor...
basically it seems less hackable, is that a wrong impression?
The way I usually put it is you have a choice: learning your tools in depth or relearning old skills each time your tools tools. I decided upon the former and firmly believe it was the right decision.
That being said, there is a cost. Tools that adapt with the times try to reduce the effort needed to get contemporary tasks done. Stable tools tend to reflect the times in which they were created (or at least peaked), meaning that it may take more effort to get things done in the here and now. Unfortunately, Emacs is very much a reflection of this.
I agree with you, I like my tools to just work. I last changed my windows manager when I started using wifi regularly over a decade ago.
Vim 8 broke this philosophy though - it changed defaults and broke workflows - changing how search works by default, breaking copy-paste by including some mouse support so when I click a line, it moves the cursor.
These aren't security improvements, these aren't transparent improvements (like allowing arrow keys as well as hjkl was way back), and they're not even odd workflows like xkcd.com/1172. Search is presumably one of the most used functions in vim, and I'm sure that clicking and highlighting text to copy into a different application isn't unusual. Changing the default behaviour is a choice that the developers made, presumably to "make vim better". I don't want vim "better", I want it stable, if I wanted "better" I'd use something that redesigns itself every 5 years.
What's worst though, is while I can adjust my workflow to automatically copy a fixed .vimrc onto any machine I ssh to, it leaves me wondering "what will change next". It's unsettling.
2021 and Emacs still my preferred editor (and I'm young enough, in my 30's). Yes it requires a bit more setup (not much more however, VSC also misses functionality out of the box). However that setup is saved forever, across machines in the form of your .emacs file, so whatever changes you make to make it personal stay with you. And it's really not much more difficult to setup, Emacs lisp is more intuitive than JSON files and as a programming language, it's pretty easy to understand that you invoke a function and then just pass it parameters, and that's about all you need to understand about it to set up the editor anyway.
But there's literally nothing I don't have with Emacs that other editors provide. I have code completion in a bunch of languages (that pops up, with documentation pop-ups), linting, snippets, a project tree preview, project awareness, etc...
> But there's literally nothing I don't have with Emacs that other editors provide.
Hmm, refactoring, fixes of Flycheck errors (if the checker/LSP provides them), a Tramp mode that actually works.
Oh, and I would like to be able to continue editing my file while Emacs is doing something else ;)
Fix-it and renames work with lsp+clangd. More complex refactoring would be nice, but in the end what is supported depends on the lsp-server capabilities.
Emacs hanging at times has unfortunately been the reality for a looong time. There is extensive async support, but it is not always used were needed.
> But there's literally nothing I don't have with Emacs that other editors provide.
I like Emacs, have an extensive personalised config and use it as my primary editor across OSes.
That said, I wish its debugging-support was better. Some simpler “just click to start debugging” options for a few popular platforms would be nice (Node, Python, .NET, Rust, whatever).
I’ve heard there are similar efforts like LSP, except for debugging. Maybe they can help out Emacs’ debugging-support, just like LSP helped improve Emacs’ auto-completion and refactoring support?
>Yes it requires a bit more setup (not much more however, VSC also misses functionality out of the box)
Not even comparable. The functionality VSC misses you can get with installing some extension, which works out of the box, with hardly any configuration, and with a very simple way to find, select, install, enable, and disable it.
>However that setup is saved forever, across machines in the form of your .emacs file
Even that's something you need to do manually in Emaca. In VSCode it's automagically synced to GitHub, and indeed is "saved forever, across machines" -- and with smart ways to handle conflicts and such if you change it elsewhere, etc.
>And it's really not much more difficult to setup, Emacs lisp is more intuitive than JSON files
VS Code has a graphical UI that abstracts away the JSON configuration files, provides autocomplete of options, limits you to available enumerated options, picks up automatically the proper UI for the config of an extension, and so on.
And even when if you want to edit the raw JSON to change the configuration, it's of course vastly easier than Lisp (a full programming language), plus it also has autocomplete for key names and values, and so on.
VSCode allows you to export settings and keybinds via JSON files.
Also, saying EMacs Lisp is more intuitive than JSON is quite absurd. You could give a 15 minute presentation on how to read JSON to someone who knows how to use Word and they’d at least be able to read it. The same wouldn’t be possible with any subset of lisp.
Well, JSON is "just" a serialization format. I'd expect that to be much easier to teach someone than a programming language. That's a rather bizarre comparison.
If all you're doing is serializing the configuration, then lisp's s-expressions are just as intuitive as JSON (in the sense that both can be explained in a few minutes).
Speaking as someone who sees a lot of students start using text editors for the first time, VSCode has two massive advantages over Emacs:
1) Most students already basically know their OS's graphical interface -- the "basic keys" like cut/copy/paste/load/save all work as expected.
2) The first time you load many common filetypes (like Java for example), a box pops up saying "Do you want me to install a nice set of standard Java plugins?"
Both points are really useful for getting started quickly, but would I imagine be really hard for emacs. The first would require changing default behaviour on first startup, the second would need accepting some set of people to decide the "default" sets of plugins.
For those who say "emacs is worth learning", that might be true, but when students can choose between Emacs, Vim, VSCode, nano, Intellij, pycharm, Eclipse, Atom, Sublime Text or Notepad++ (that's all the editors I think I've seen in the last year), they need a special reason to give emacs all that extra work needed to understand it.
Vim/Neovim had a bump a few years ago and got really popular (although that might be over now, at least on my limited experience). I think that was because there were obvious improvements going on, which attracted students to take a look.
> The first time you load many common filetypes (like Java for example), a box pops up saying "Do you want me to install a nice set of standard Java plugins?"
This. Used Emacs for fifteen years professionally, and I gave up when I had to reinstall my laptop, as having intellisense-like features and easy navigation in Emacs is a complete pain.
I actually did not intent to switch to VSCode, but after a couple of hours of scratching my head with list configuration files, I ended up "trying" VSCode, and after a couple of _minutes_, everything was working (completion, navigation etc.)
After a couple of tweaking, clangd was plugged, and I had direct visual compiler feedback in realtime while typing code in the window.
I've used Emacs for 30 years, and I have no intention of ever giving it up, but IMO this is somewhat accurate. The package installation and configuration story on Emacs has gotten a lot better over the last ten years or so, but there really ought to be a kind of meta package installer and configurator that does exactly what VSCode does: when it finds a file that it doesn't handle specially but for which there is an existing package or set of packages, install those packages and configure them with reasonable defaults.
Spacemacs does this, which is the main nice thing about it. Unfortunately, it also carries a lot of other baggage rather than just doing this.
Vim is different enough that when its fans say it's superior, at least some people think it's plausible enough that it's worth learning. And even if they don't become appreciably more productive by it, at that point it's sunk cost and they might as well keep using it.
The last time I had any reason to consider getting into emacs, was when I came across a proof assistant many years ago that basically required it - it used emacs to provide an interactive interface. Not unlike how everyone uses electron/chrome these days to quickly provide a familiar interactive interface. It was like an exotic artefact from a parallel universe where emacs' conventions became dominant instead of IBM and Microsoft's.
I personally love Vim because once you know how to work it, you can code extremely quickly. You don’t really even need any macros (though they can make you even faster) — I find the default commands to be fast enough that I consider vim to be an “expert interface” for text editing.
Computer Science students would greatly benefit from an introductory-level course in the two of the most historically influential languages -- LISP and Smalltalk.
Emacs as an editor does take effort to learn, and it's a different type of effort from all the other editors you mention, because they are all quite different beasts.
In the end, it comes down to pedagogical considerations and how each individual learns.
Emacs has suffered by having an awfully austere default installation, and Linux distributions have refrained from delivering a version with something like Doom or Prelude to make it more approachable. (Prelude is my favourite.)
Not always with those two languages, but in many CS curricula in the US there is a "programming languages" course that covers between 4 and 10 [0] languages in different language families. Prolog and Common Lisp (or Scheme) are typically included, you may get Smalltalk in there depending on the school. It's brief, because it's one course, but it's usually a 3rd year course so students should be competent programmers by then (that is, an Algorithms 101 course but in Lisp would be a slog for them).
Other schools make a point (or made, not sure the current state) of changing languages between courses in the first couple years and giving more choice to students later. Like, an OO course would have been taught with Smalltalk after an intro algorithms/data structures course sequence using Java, Python, or other languages. A compilers course may have used SML, but it wasn't an SML course, just a compilers course that happened to use SML.
[0] The most I've seen, it was absurdly paced, an intern was taking that one.
> 2) The first time you load many common filetypes (like Java for example), a box pops up saying "Do you want me to install a nice set of standard Java plugins?"
Spacemacs also does this, and it's a big part of why I stuck around long enough to discover some of the plugins that make the Emacs world really special, like Org mode and Magit.
I'm still no Emacs hacker, but I know enough to get by, and that a good starter kit can make me productive in Emacs in just a few minutes.
> Both points are really useful for getting started quickly, but would I imagine be really hard for emacs. The first would require changing default behaviour on first startup, the second would need accepting some set of people to decide the "default" sets of plugins.
I actually don't think these are very hard from a technical perspective.
The first has been done in the past. Aquamacs was a version of Emacs for Mac OS that supported conventional Mac keyboard shortcuts, in addition to the Emacs ones.
The second should really just be a matter of matching certain file extensions and prompting to download the most popular mode for that file type. The Emacs package manager is very good, so it's a simple change to just include a mapping from file extension to Emacs package and trigger the prompt when opening a file of a given type for the first time.
Emacs' fundamental problem is that in text editing, there are many equally good ways to do things.
It's equally good for Undo to be on control _ as on control z. It's equally good for scrolling to move the cursor as to not move it. It's equally good to have Lisp as a scripting language as JavaScript. No, really, I mean it. It's not a big deal in the big picture.
And Emacs choose perfectly good, perfectly sensible defaults on all these things back when it came. (That can't be said about all editors from that time.)
It's just that in the 30+ years since, the world has converged on other defaults. Every little thing is done different than you're almost certainly used to - yet not different enough that anyone can claim it's somehow superior (unlike its modal cousins from the same period. I think their claim is dead wrong, but at least it's different enough that they can persuade some).
This sounds like it's not written by an actual Emacs user... and the fact that I can tell points to the real fundamental problem of Emacs: it's not a text editor but the real thing it is is so complicated it finds it easier to market itself as a mere text editor.
What is Emacs really? It's a virtual Lisp machine with a standard library for writing graphical text applications. It's more like the JVM than like Notepad.
It just happens to come bundled with a text editor (and a file manager, and a calculator, etc) as example applications. You're free to install a better text editor than the bundled example, and many people to (see the popularity of Evil, for example).
But of course, this is a much more complicated point in space to sit in, so Emacs markets itself primarily as a text editor and we get confusion like yours as a result.
This is something I wish someone had told me 20 years ago when I first started using emacs. The whole "it's a text editor, but also it's not really a text editor"-thing was very confusing initially.
... Although, now that I think about it, being told this mind-blowing revelation about the emacs nature might have confused me even more.
What I love about emacs is that I have a variety - an extensible variety! - of programs under one roof, so to speak, sharing the same - customizable! - keyboard shortcuts that comfortably integrate with each other.
I think the main problem in "proselytizing" emacs to potential new users is that it is kind of the C++ of text editors, in the sense that it takes a very big up front investment that does pay off in a big way if you persist, but getting to that point took - at least for me - a multi-year commitment. It is hard to sell someone on that unless they want to do it anyway. I did it out of fun and curiosity, but if you view it as an investment in purely transactional terms, it's hard to sell.
In a couple months I'll have been using emacs for 30 years, and it seemed like a pretty good summary to me. In that time the closest I've gotten to using any of the lisp stuff is setting some variables in my .emacs file. (and it's been fewer of those as the year go by)
I never claimed to be an emacs user. I've used Linux exclusively at home since 2001, and I've never "switched" to it or vim, though of course I have a passing familiarity with both from such things as certifications or working on other people's machines.
Of course I'm familiar with the "never leave emacs" meme, moon phase indicators and "what it needs is a good editor" etc. I even gave an example of it being used as a platform in my other comment here (proof general).
But this was about its popularity relative to other editors, not relative to other scriptable framework things.
It's an early web browser. Elisp is an early JS. Viewing documents is just a little more complicated (download packages, sync stuff down using Git, etc)
>>What is Emacs really? It's a virtual Lisp machine with a standard library for writing graphical text applications. It's more like the JVM than like Notepad.
Well then in that case, ship a better Lisp than emacs lisp?
I can do things no other would let me do easily. Namely: create automatic exams with latex, each for a different address and send each to its corresponding pupil, all in a single script.
Well, Ctrl-_ is three keys; control, shift and _. However, Undo in Emacs is actually designed to be on the two-key combination Ctrl-/ and the fact that this key produces the same ASCII control code as Ctrl-_ is incidental.
It's absolutely true that defaults are "bad" in many modern environments (though remember C-z to suspend in a terminal environment makes perfect sense!).
But the nature of the editor is customization like this. People unwilling to do this just aren't ever going to be happy with emacs. And for those just learning, tricks like that (c.f. emacswiki.org) are a very reasonable entryway into a world of possibilities.
I mean, look, Emacs isn't ever going to be VSCode. If you want VSCode, use VSCode. It's a great editor, and frankly at this stage I think nothing is going to do VSCode better than VSCode already has. Emacs is something different, and we might as well embrace that.
(Not that I'd object to switching some of the dumb defaults around, of course. I just don't think that's going to help very much if your goal is "displace VSCode").
The biggest problem for me is the constant context switching between those defaults chosen 30 years ago and the defaults converged on by every other app I use.
Of course, no context switching is needed if you do everything in Emacs.
Actually, ounce I got used to Emacs choices I ended up liking them better. Hard to say why, I think it's that when you start adding more and more shortcuts, the choices Emacs made start to make sense in terms of maximizing all the various bindings.
I would be very happy if I could use Emacs’ text editing and text manipulation/navigation everywhere. Things like a real IDE with an Emacs editor. Or the IDE being controlled by Emacs. Or a desktop manager controlled by Emacs.
That Emacs lets you design a great user interface is exactly why some people want to “live in Emacs”. (Similar to how some misguided souls prefer to “live in the terminal”...)
I've been using emacs as my primary editor since 1989. It has for that entire time been a PITA to configure. My first customization was to map backspace to ^H and map the insert key to 'nil.
I used to dedicate a couple days every January to investigate new emacs tools. Read about the latest features or new modes, often from my org-mode TODO list where I bookmarked them. I have learned to never update emacs mid-project as I've on multiple occasions shattered my emacs config updating versions or moving to a new distros. MacOS brew install vs .dmg install? Aquaemacs? DoomEmacs? Oh, hello the malpa repo URL changed and is https only now.
VSCode has a healthy extension marketplace, something emacs should adopt.
elisp is dead. Not because it is dead, or deserves to be dead, but because everyone "believes" it dead. Same goes for Perl.
I love emacs, it has been a rock my entire programming life, but it's a time suck to configure. I know there are some who have created a Sistine Chapel in their .emacs.d, and I'm jealous. There's a fine balance between spending time and effort optimizing and sharpening your tools and emacs is deep on the wrong side of the line for me.
I don't want emacs to ever die. But come on, if you're losing to vim in popularity, you are already dead.
I’m not sure it was ever alive to begin with. Not in the classical sense. I mean, I don’t think elisp ever got good (or any) use outside of emacs configuration and extension. There weren’t any popular web frameworks, numerical libraries etc. written in elisp.
Inside its target space, though, it seems as vibrant as ever. New, helpful packages keep appearing that are written in elisp. For better or worse, the extension ecosystem is not nearly as fragmented as some other editors.
That’s not to say that elisp doesn’t need serious improvements, though. Making it natively multi threaded alone will advance the story quite a bit imo.
Common mistake. The problem is procrastination and bike shedding, not emacs. It’s because some people love their tools, sometimes more than the craft.
It’s the same with cars, photography and woodworking.
Maybe because hacking emacs lisp, supercharging a Miata, retro-fitting lenses or Tuning a pre-war Stanley handplane feels as good as using them.
>>everyone "believes" it dead. Same goes for Perl.
This week I did with Python what I used to generally do with Perl. Write big throwaway programs, written quickly. I realise this was possible because Python has been heavily Perlified over time.
That way we just managed to write Perl in Python, by converting Python to Perl.
> elisp is dead. Not because it is dead, or deserves to be dead, but because everyone "believes" it dead. Same goes for Perl.
I wonder if it's possible to move on from elisp. Create a EMACS 2. Maybe with Scheme. Maybe a language neutral extension system/API? (So you can use whatever language you want.)
I see many people on here (likely non-emacs users) claiming that Emacs is obsolete/outdated/dying by completely misunderstanding its position in the ecosystem.
Maybe it's easier to understand via analogy. Let's consider cars. Of the global population of car users, relatively few of them are F1 racecar drivers. Furthermore, you can easily make the case that the particular features (aerodynamics, speed etc.) that make the F1 a good racecar, would not be useful for the average driver - the time they spend honing their skills to handle such a beast, you could argue, would be better spent on other things. But, at the same time, the F1 car has and will continue to have a place in the car ecosystem.
In the case of developers, you might be right that, for the average developer, working on your run of the mill, mundane, forgotten-in-a-few-years, CRUD web apps, a normal _average_ car (M$ vscode) would be a better investment, but no matter what, you will never be as fast or flexible as an F1 car (GNU Emacs).
I just love that for a moment here we’ve put aside our differences about emacs vs vi and focused our efforts on bike shedding which car analogy best fits. Peak computing culture.
I wouldn't waste keystrokes on the classic religious war being waged in this thread so I'm gonna throw my hat in this arena instead. I agree with you---that analogy sucks.
Being able to drive an F1 car comes with excellent financial opportunities. Even if I'm not "on the grid" (i.e., actively competing in the GPs), I can be a test driver. Heck the license required to drive an F1 car opens other doors in itself (maybe in other motorsports, but also allegedly the range of vehicles you can drive).
In contrast, if I am proficient in emacs I am...proficient in emacs. I edit code in a manner that is visually impressive to maybe three persons in the CS department. I'd have an ever-so-slightly deeper connection to RMS than your average CRUD-slinger. I am out of advantages to enumerate and I'm trying very hard.
Maybe text editors are about as similar to cars as apples are to buildings.
you will never be as fast or flexible as an F1 car
F1 race cars are literally the least flexible cars available. They are designed for exactly one type of racing and there is hardly anything you are allowed to configure the way you want. There are cars with higher top speeds than F1 cars, and cars that accelerate faster. A $2k second hand Honda Civic will beat the crap out of an F1 car around a gravel track. F1 cars aren't even the fastest design for racing on F1 race tracks. F1 cars are only good for one thing, and that is winning F1 races.
Having worked in F1 that's entirely wrong. A Honda Civic will not even beat a F1 car in the first gear, which goes up to 180km/h. With an unlimited engine of ~24k rpm and a chassis which sucks around each curve nothing can be compared to a F1. If there are curves. On a straight track there are faster cars for about 4 seconds, but then the F1 overtakes. Our usual estimate was that everything in a F1 car was about 1000x better than in other cars. Gearbox? Engine? Chassis? ECU, TCU, tires, you name it
It sounds like you know very little about either F1 cars or Emacs. Emacs is more like an older Toyota pickup truck – been around for a long time, ubiquitous, flexible, can carry a load, simple, there's an abundance of spare parts, and there's no problem with it that a good mechanic cannot fix – most problems can be fixed even by improvisation in the field.
I used Emacs, its a lot more than just a simple text editor, its more powerful than a text editor or even many IDEs. But the learning curve is too steep for most people. With VScode I can just install it and start working straight away, I cant really do that with Emacs. I dont want Emacs to die out or fade away, but lets be honest its for a much smaller group of users. It they want it to be be popular it would have to change, but then it wouldnt be Emacs anymore.
There's that condescending attitude again. In your fantasy land Emacs is an F1 race car, and everyone else is a CRUD-writing code monkey that drives a cheap sedan.
In reality though, Emacs is a subpar editor for both everyday and specialized tasks that's fallen into obscurity as its maintainers refuse to implement anything that would make it keep up the pace with superior editors.
With 15+ years of daily Emacs usage, I couldn't agree more. It's 50% force of habit, and 50% the few commands (align-regexp! kill-rectangle!), packages (magit! tramp!), or custom Lisp snippets that make every other editor feel inadequate...
Until your Emacs process is hung again, waiting for IO, or can't process a "jump to definition", or chokes on a file with extremely long lines, or the stitched-together macOS dark mode switcher daemon has crashed, ad infinitum.
Yes, it's a race car, but from 1987, and in total disrepair.
> but no matter what, you will never be as fast or flexible as an F1 car (GNU Emacs).
The massive flaw in your analogy being that Emacs has more to do with an old and crumbling collection racing car than a F1. Its users constantly need to tinker it to make it somewhat run like a normal car. It’s still slower and less ergonomic but they are blinded by their love and habit to its obvious flaws.
The amount of IDE and editors that just work well with little customisation and have great refactoring features is now so high, it leaves little place for emacs.
Emacs is more like a car from a Mad Max film than it is an F1 racer: each instance of Emacs has been so heavily modified (often in haphazard, kitbash fashion) that it's only ever supposed to be driven by one person: its owner.
I think a better analogy would be comparing a Mercedes W123 (Vim/Neovim) with a Toyota Camry or Honda Accord (VSCode/Jetbrains) with a Jeep Wrangler (Emacs).
Yes, the Jeep Wrangler will topple over while trying to go through a ravine (which no other mass-produced four-wheeled vehicle would ever be capable of going through), but that's what after-market rollcages are for.
I don't want to sound rude but I've never seen a well executed car analogy, especially when they use F1 racecars. Your analogy doesn't make the position of Emacs easier to understand at all.
> I've never seen a well executed car analogy, especially when they use F1 racecars.
An F1-analogue editor would be incredibly fragile, narrowly focused, and demand a huge amount of maintenance.
For the last, both this HN discussion and IIRC TFA offer widely varying estimates as to how much people need to tinker with their configuration files. For the others, only being able to run on one kind of track (absolutely flat ones) would be for an editor to only work for one programming language; spinning and flying into bits at the slightest touch would be for the editor to crash as soon as you type in bad syntax or misspell a variable name; and needing the engine rebuilt after each race and replaced every third or fourth would be... I'm not sure, needing to update to a new version of your editor every three or four weeks?
If Emacs is like any sort of car, it's certainly not an F1 one.
The VS Code/normal car and emacs/F1 racer analogy seems weak. VS Code can bring most of the functionality of a relatively well tuned and customized vim or emacs setup to a much broader range of developers, and with very little investment. Less time spent gold-plating and polishing an editor's configuration is more time spent solving actual problems.
There is no world, in which "flexible" and "F1 Car" belong in the same sentence. By design, a track car gets rid of anything "flexible" for highly optimized choices.
If we want to assign a car to emacs, it's more like a Toyota Tacoma, with no body. Rugged, flexible, some basic building blocks that function out of the box.
I don't think your analogy holds up. If you race an F1 car alongside a commuter sedan, it is obvious to anyone observing the differences in performance, handling, traction, etc.
So going by results, if emacs was so awesome and if it gave such a huge boost, then we would see those results, and it would be trivial to convince anyone to switch to it.
Personally, I don't see editing text as a bottleneck for developer productivity. The vast majority of time is spent reading code, thinking about code, stepping through/debugging code, reading specs, etc. Yes, emacs can do those things to (as can any system that supports plugins), but my point is that we don't see a 'competitive edge' where all the most productive developers use X. What we see is productive developers using a wide variety of tools. Going back to your F1 analogy, there isn't a single sedan winning F1 races.
Hmmm... I agree that Emacs is specialist, but at least half the reason I don't use it is that it tends to be fairly sluggish if you start really configuring it and using it.
Rather than an F1 race car, maybe the analogy would be better made to one of those backhoe/front loader combos. While it won't do simple operations like getting you from point 'A' to point 'B' as quickly, you can do more once you get there as compared to the family sedan. Of course, once you do get there you have to invest substantial time learning how to use the backhoe, the front loader, how not to tip it over, how not to inadvertently break stuff with it, etc. But once you've taken all that time and practiced it enough... you can do quite a lot.
> claiming that Emacs is obsolete/outdated/dying
> run of the mill, mundane, forgotten-in-a-few-years, CRUD web apps, a normal _average_ car (M$ vscode)
With regards to obsolete and outdated - I started using vi and emacs back in 1989 (I currently use vi more). The keybindings and such I learned back then are still relevant.
In my day job, I mostly program Android. Before 2014, I programmed with Eclipse and an Android plugin, which is what Google suggested. Then Android Studio was released, which is what Google suggested. As I haven't used Eclipse at all since around 2014-2015, Eclipse, to me any how, has become "obsolete/outdated". Yet I'm still using vi (and emacs) as I have since the 1980s. They have not become outdated, I still use them as I always have.
If you want to continue this analogy, I don't want a 30 year old F1 car. Also, as with old cars there is a bunch of people who are determined everything invented in the last 30 years is stupid, and we should stick with "good old reliable" things.
Most people want a newer car, that's picked up the improvements in safety and performance from the last 30 years.
A better analogy is a non fuel injector vehicle that doesn’t need electronics to fix, is old and consistent, that works the same. It’s like x.org, you can rely on it to not change the UI constantly (like gnome breaking something in every version).
I understand why there's all this concern about making Emacs popular--as software professionals, we've all seen a few tools that we use and love wither at the vine and die slow deaths. But the concern for _overall_ popularity is a little misplaced. There's more developers than ever, and the pie continues to grow; Emacs just needs a sufficient total userbase to stay maintained, and that seems already to be in place.
The greatest threat to Emacs, as to any other fairly well-liked open-source editor, is a paradigm change in how software gets built or run, not whether it has 7% or 9% mindshare.
I agree with this. I used emacs in the late 90s through early 00s, and it worked great. I pretty much stick with BBEdit these days, because it works great for my personal workflow. I never got into vim: I only learned enough of it to edit config files and the like when I shell into a computer.
The modern paradigm of running npm/brew/composer/webpack/whatever gimcrack tool that gets shoehorned into the build process has led a lot of people to the VSCode-ish side of things that make integrating these things easy. emacs tends to look like a well-appointed workshop with lots of good, sharp tools and a stack of raw lumber, whereas VSCode looks like a finished Chesterfield. It takes a certain sort of person to prefer the workshop over the finished piece, and I'm not sure you could ever change that.
I see where you're going - but I've personally noticed that there are a lot of things coming along with these cloud infrastructure paradigms that have made me feel like my localhost text editing workflows are going to make me look and feel even more like an absolute dinosaur as time goes on. I can't speak eloquently on this as I'm still an amateur to these cloud infra configuration concepts and their real limitations on how I'm used to thinking about application development, but I hope this comment sparks some inspiration for someone else to do so.
I use Emacs (with Evil) daily, and despite having tried to move to other editors I'm locked into Emacs. Not so much because of the functionality of Emacs itself but because of plugins...
First, Emacs has the best Vim compatibility I've seen outside of Vim itself. Visual Studio is probably "good enough" for me on this with the vim plugin, but that 5% difference in compatibility makes a difference in practice.
But the largest reason I can't get away from Emacs is Ivy/Counsel. Being able to fuzzy search on the current file or entire project, see results, jump around to each one to see context, make changes to the results in an occur buffer to selectively mass edit search results...all of that I just haven't found a replacement for. Search/replace just doesn't cut it.
So effectively if I move to another editor, my code navigation time increases by 5-10x. Things like better autocomplete might fill that gap, but just even understanding how things go together is so much more difficult when you're fighting with your editor.
Add on other things like org-roam, buffer fuzzy searching in Ivy, fasd tie-in, the customization options, etc, and Emacs is just an amazing experience. There are definitely things I would change, like inline debugging (which I use VS Code for instead), setting up languages and autocomplete, etc. Getting things just right takes a long time for a new language.
Nvim has some plugins and features that do some of the things you might be interested in. Telescope[0][1] which is a fuzzy finder for anything you can think of (files, symbols, color themes, etc.[2]). The LSP and Treesitter stuff in nvim 0.5+ is also pretty cool. If you want to just try it without much work the Lunarvim[3] project comes with sane defaults and included plugins (including Telescope).
Lua as the default configuration language makes things simple to configure as well.
Having said all that...if someone told me [insert-text-editor] had everything I would want I would probably check it out and go home to vim (but I do enjoy learning about new stuff and features).
The diversity in the emacs ecosystem has a hand in this I think. There are so many different ways to switch buffers: vanilla, Ido, Helm, Ivy, and all of the other ones I haven't heard about. This kind of diversity is unseen in other consolidated, centrally managed software ecosystems.
And those aren't just ways to switch buffers - they're options on a 'select among choices' dimension that's totally orthogonal to 'things that generate choices to select'. List of buffers, list of commands, list of files in a project ... can be presented, narrowed, and selected in an interface chosen by the user
Readit News
How... Uh, how do you use computers then? Isn't everything we do with them in some way through "an app"?
1. Missing out on "new innovations" (and using older gui/etc paradigms which don't mesh with anything else you are used to).
2. Finding ways to update your tool to take advantage of "new innovations", which costs time, and often gives you a worse outcome.
I was a vim user for 8 years, then used spacemacs for another 2, but have lately switched to VSCode (with vim mode, obviously). The ease of just downloading vscode and having it work with almost no tinkering, having it look good, and being able to, for the most part, double-click an extension name if I need it... that ease of use means that whatever learning curve I do have to pay sometimes, it's worth it.
(And the learning curve for making VSCode have the vim/emacs features I need was tiny compared to managing my vim/emacs config).
Vim and Emacs are console editors for me. The most significant difference for me is sensible mouse support. I used Emacs just for LaTeX, otherwise I use mostly unhacked vim. It is very useful to be familiar with one of them, but nano is awesome too and I always mention it for new developers.
I believe vscode is successful because it is simple. Just like how JSON was successful compared to XML for simple applications. It isn't better than XML, but most applications are too simple to warrant XML features and resulting complexity.
For C# I prefer VS instead of vscode and I fear vscode tries to be both, a code editor with extended features vs a fully integrated IDE. For some language like JS vscode already has become an IDE with advantages and disadvantages and it is quite often very opinionated here.
basically it seems less hackable, is that a wrong impression?
(and json files don't allow for comments right?)
That being said, there is a cost. Tools that adapt with the times try to reduce the effort needed to get contemporary tasks done. Stable tools tend to reflect the times in which they were created (or at least peaked), meaning that it may take more effort to get things done in the here and now. Unfortunately, Emacs is very much a reflection of this.
Vim 8 broke this philosophy though - it changed defaults and broke workflows - changing how search works by default, breaking copy-paste by including some mouse support so when I click a line, it moves the cursor.
These aren't security improvements, these aren't transparent improvements (like allowing arrow keys as well as hjkl was way back), and they're not even odd workflows like xkcd.com/1172. Search is presumably one of the most used functions in vim, and I'm sure that clicking and highlighting text to copy into a different application isn't unusual. Changing the default behaviour is a choice that the developers made, presumably to "make vim better". I don't want vim "better", I want it stable, if I wanted "better" I'd use something that redesigns itself every 5 years.
What's worst though, is while I can adjust my workflow to automatically copy a fixed .vimrc onto any machine I ssh to, it leaves me wondering "what will change next". It's unsettling.
Deleted Comment
But there's literally nothing I don't have with Emacs that other editors provide. I have code completion in a bunch of languages (that pops up, with documentation pop-ups), linting, snippets, a project tree preview, project awareness, etc...
Hmm, refactoring, fixes of Flycheck errors (if the checker/LSP provides them), a Tramp mode that actually works. Oh, and I would like to be able to continue editing my file while Emacs is doing something else ;)
Emacs hanging at times has unfortunately been the reality for a looong time. There is extensive async support, but it is not always used were needed.
I like Emacs, have an extensive personalised config and use it as my primary editor across OSes.
That said, I wish its debugging-support was better. Some simpler “just click to start debugging” options for a few popular platforms would be nice (Node, Python, .NET, Rust, whatever).
I’ve heard there are similar efforts like LSP, except for debugging. Maybe they can help out Emacs’ debugging-support, just like LSP helped improve Emacs’ auto-completion and refactoring support?
[1] https://github.com/emacs-lsp/dap-mode
Until you use a plugin which is dead after the next update. Which happens a lot...
> Emacs lisp is more intuitive than JSON files
Not really. In the first place JSON is just data-format which usually is used through a proper GUI. There is not much you can do break there.
> But there's literally nothing I don't have with Emacs that other editors provide.
Which only means your horizon is too small to know the missing parts. Or your work is not specific enough to demand something not available in emacs.
If you are satisfied with emacs, ok. Good for you. But how will it benefit the popularity of emacs?
Deleted Comment
Not even comparable. The functionality VSC misses you can get with installing some extension, which works out of the box, with hardly any configuration, and with a very simple way to find, select, install, enable, and disable it.
>However that setup is saved forever, across machines in the form of your .emacs file
Even that's something you need to do manually in Emaca. In VSCode it's automagically synced to GitHub, and indeed is "saved forever, across machines" -- and with smart ways to handle conflicts and such if you change it elsewhere, etc.
>And it's really not much more difficult to setup, Emacs lisp is more intuitive than JSON files
VS Code has a graphical UI that abstracts away the JSON configuration files, provides autocomplete of options, limits you to available enumerated options, picks up automatically the proper UI for the config of an extension, and so on.
And even when if you want to edit the raw JSON to change the configuration, it's of course vastly easier than Lisp (a full programming language), plus it also has autocomplete for key names and values, and so on.
Also, saying EMacs Lisp is more intuitive than JSON is quite absurd. You could give a 15 minute presentation on how to read JSON to someone who knows how to use Word and they’d at least be able to read it. The same wouldn’t be possible with any subset of lisp.
If all you're doing is serializing the configuration, then lisp's s-expressions are just as intuitive as JSON (in the sense that both can be explained in a few minutes).
Some IDEs that can semi-compile the code (to something like an AST) can provide a lot more support for refactoring correctly.
Plenty of Emacs plugins invoke a compiler, language server, whatever to get information about the code. That isn't a feature unique to IDEs.
Time.
Other editors save you play time you need to spend with emacs to get it to anywhere close to usable.
1) Most students already basically know their OS's graphical interface -- the "basic keys" like cut/copy/paste/load/save all work as expected.
2) The first time you load many common filetypes (like Java for example), a box pops up saying "Do you want me to install a nice set of standard Java plugins?"
Both points are really useful for getting started quickly, but would I imagine be really hard for emacs. The first would require changing default behaviour on first startup, the second would need accepting some set of people to decide the "default" sets of plugins.
For those who say "emacs is worth learning", that might be true, but when students can choose between Emacs, Vim, VSCode, nano, Intellij, pycharm, Eclipse, Atom, Sublime Text or Notepad++ (that's all the editors I think I've seen in the last year), they need a special reason to give emacs all that extra work needed to understand it.
Vim/Neovim had a bump a few years ago and got really popular (although that might be over now, at least on my limited experience). I think that was because there were obvious improvements going on, which attracted students to take a look.
This. Used Emacs for fifteen years professionally, and I gave up when I had to reinstall my laptop, as having intellisense-like features and easy navigation in Emacs is a complete pain.
I actually did not intent to switch to VSCode, but after a couple of hours of scratching my head with list configuration files, I ended up "trying" VSCode, and after a couple of _minutes_, everything was working (completion, navigation etc.)
After a couple of tweaking, clangd was plugged, and I had direct visual compiler feedback in realtime while typing code in the window.
VSCode is not "better". It's just another world.
Spacemacs does this, which is the main nice thing about it. Unfortunately, it also carries a lot of other baggage rather than just doing this.
The last time I had any reason to consider getting into emacs, was when I came across a proof assistant many years ago that basically required it - it used emacs to provide an interactive interface. Not unlike how everyone uses electron/chrome these days to quickly provide a familiar interactive interface. It was like an exotic artefact from a parallel universe where emacs' conventions became dominant instead of IBM and Microsoft's.
Also love the VS Code vim plug-in.
Emacs as an editor does take effort to learn, and it's a different type of effort from all the other editors you mention, because they are all quite different beasts.
In the end, it comes down to pedagogical considerations and how each individual learns.
Emacs has suffered by having an awfully austere default installation, and Linux distributions have refrained from delivering a version with something like Doom or Prelude to make it more approachable. (Prelude is my favourite.)
Other schools make a point (or made, not sure the current state) of changing languages between courses in the first couple years and giving more choice to students later. Like, an OO course would have been taught with Smalltalk after an intro algorithms/data structures course sequence using Java, Python, or other languages. A compilers course may have used SML, but it wasn't an SML course, just a compilers course that happened to use SML.
[0] The most I've seen, it was absurdly paced, an intern was taking that one.
Spacemacs also does this, and it's a big part of why I stuck around long enough to discover some of the plugins that make the Emacs world really special, like Org mode and Magit.
I'm still no Emacs hacker, but I know enough to get by, and that a good starter kit can make me productive in Emacs in just a few minutes.
Though one day I will bother to configure emacs from scratch, but that day is not today.
I actually don't think these are very hard from a technical perspective.
The first has been done in the past. Aquamacs was a version of Emacs for Mac OS that supported conventional Mac keyboard shortcuts, in addition to the Emacs ones.
The second should really just be a matter of matching certain file extensions and prompting to download the most popular mode for that file type. The Emacs package manager is very good, so it's a simple change to just include a mapping from file extension to Emacs package and trigger the prompt when opening a file of a given type for the first time.
It's equally good for Undo to be on control _ as on control z. It's equally good for scrolling to move the cursor as to not move it. It's equally good to have Lisp as a scripting language as JavaScript. No, really, I mean it. It's not a big deal in the big picture.
And Emacs choose perfectly good, perfectly sensible defaults on all these things back when it came. (That can't be said about all editors from that time.)
It's just that in the 30+ years since, the world has converged on other defaults. Every little thing is done different than you're almost certainly used to - yet not different enough that anyone can claim it's somehow superior (unlike its modal cousins from the same period. I think their claim is dead wrong, but at least it's different enough that they can persuade some).
What is Emacs really? It's a virtual Lisp machine with a standard library for writing graphical text applications. It's more like the JVM than like Notepad.
It just happens to come bundled with a text editor (and a file manager, and a calculator, etc) as example applications. You're free to install a better text editor than the bundled example, and many people to (see the popularity of Evil, for example).
But of course, this is a much more complicated point in space to sit in, so Emacs markets itself primarily as a text editor and we get confusion like yours as a result.
... Although, now that I think about it, being told this mind-blowing revelation about the emacs nature might have confused me even more.
What I love about emacs is that I have a variety - an extensible variety! - of programs under one roof, so to speak, sharing the same - customizable! - keyboard shortcuts that comfortably integrate with each other.
I think the main problem in "proselytizing" emacs to potential new users is that it is kind of the C++ of text editors, in the sense that it takes a very big up front investment that does pay off in a big way if you persist, but getting to that point took - at least for me - a multi-year commitment. It is hard to sell someone on that unless they want to do it anyway. I did it out of fun and curiosity, but if you view it as an investment in purely transactional terms, it's hard to sell.
If you substitute Javascript for Lisp, doesn't that describe Visual Studio Code pretty well?
So now there's a product that leverages the architectural advantages of Emacs, with modern defaults across the board.
Of course I'm familiar with the "never leave emacs" meme, moon phase indicators and "what it needs is a good editor" etc. I even gave an example of it being used as a platform in my other comment here (proof general).
But this was about its popularity relative to other editors, not relative to other scriptable framework things.
Well then in that case, ship a better Lisp than emacs lisp?
- magit :: everyday things are just a key away, less common things are visible, complex things are possible
- Org-mode :: whole life in plain text (for some brain types it enables almost impossible to achieve otherwise + Org-Babel + emacs-jupyter
I can do things no other would let me do easily. Namely: create automatic exams with latex, each for a different address and send each to its corresponding pupil, all in a single script.
Attaching is a breeze, by the way.
Well, Ctrl-_ is three keys; control, shift and _. However, Undo in Emacs is actually designed to be on the two-key combination Ctrl-/ and the fact that this key produces the same ASCII control code as Ctrl-_ is incidental.
But the nature of the editor is customization like this. People unwilling to do this just aren't ever going to be happy with emacs. And for those just learning, tricks like that (c.f. emacswiki.org) are a very reasonable entryway into a world of possibilities.
I mean, look, Emacs isn't ever going to be VSCode. If you want VSCode, use VSCode. It's a great editor, and frankly at this stage I think nothing is going to do VSCode better than VSCode already has. Emacs is something different, and we might as well embrace that.
(Not that I'd object to switching some of the dumb defaults around, of course. I just don't think that's going to help very much if your goal is "displace VSCode").
Of course, no context switching is needed if you do everything in Emacs.
People trying to learn very deep kind of software should be ready to swallow a little more info than that IMO.
Out of genuinely interest, what claims specifically are you addressing here and why do you think are they wrong?
That Emacs lets you design a great user interface is exactly why some people want to “live in Emacs”. (Similar to how some misguided souls prefer to “live in the terminal”...)
I used to dedicate a couple days every January to investigate new emacs tools. Read about the latest features or new modes, often from my org-mode TODO list where I bookmarked them. I have learned to never update emacs mid-project as I've on multiple occasions shattered my emacs config updating versions or moving to a new distros. MacOS brew install vs .dmg install? Aquaemacs? DoomEmacs? Oh, hello the malpa repo URL changed and is https only now.
"eldoc" error wrong-type-argument stringp number-or-marker-p
Googling that doesn't get you anywhere.
VSCode has a healthy extension marketplace, something emacs should adopt.
elisp is dead. Not because it is dead, or deserves to be dead, but because everyone "believes" it dead. Same goes for Perl.
I love emacs, it has been a rock my entire programming life, but it's a time suck to configure. I know there are some who have created a Sistine Chapel in their .emacs.d, and I'm jealous. There's a fine balance between spending time and effort optimizing and sharpening your tools and emacs is deep on the wrong side of the line for me.
I don't want emacs to ever die. But come on, if you're losing to vim in popularity, you are already dead.
I’m not sure it was ever alive to begin with. Not in the classical sense. I mean, I don’t think elisp ever got good (or any) use outside of emacs configuration and extension. There weren’t any popular web frameworks, numerical libraries etc. written in elisp.
Inside its target space, though, it seems as vibrant as ever. New, helpful packages keep appearing that are written in elisp. For better or worse, the extension ecosystem is not nearly as fragmented as some other editors.
That’s not to say that elisp doesn’t need serious improvements, though. Making it natively multi threaded alone will advance the story quite a bit imo.
What’s wrong with MELPA?
Common mistake. The problem is procrastination and bike shedding, not emacs. It’s because some people love their tools, sometimes more than the craft. It’s the same with cars, photography and woodworking. Maybe because hacking emacs lisp, supercharging a Miata, retro-fitting lenses or Tuning a pre-war Stanley handplane feels as good as using them.
This week I did with Python what I used to generally do with Perl. Write big throwaway programs, written quickly. I realise this was possible because Python has been heavily Perlified over time.
That way we just managed to write Perl in Python, by converting Python to Perl.
Python is Perl 6.
I guess I'm a necromancer.
I'm ok with this.
I wonder if it's possible to move on from elisp. Create a EMACS 2. Maybe with Scheme. Maybe a language neutral extension system/API? (So you can use whatever language you want.)
Maybe it's easier to understand via analogy. Let's consider cars. Of the global population of car users, relatively few of them are F1 racecar drivers. Furthermore, you can easily make the case that the particular features (aerodynamics, speed etc.) that make the F1 a good racecar, would not be useful for the average driver - the time they spend honing their skills to handle such a beast, you could argue, would be better spent on other things. But, at the same time, the F1 car has and will continue to have a place in the car ecosystem.
In the case of developers, you might be right that, for the average developer, working on your run of the mill, mundane, forgotten-in-a-few-years, CRUD web apps, a normal _average_ car (M$ vscode) would be a better investment, but no matter what, you will never be as fast or flexible as an F1 car (GNU Emacs).
Being able to drive an F1 car comes with excellent financial opportunities. Even if I'm not "on the grid" (i.e., actively competing in the GPs), I can be a test driver. Heck the license required to drive an F1 car opens other doors in itself (maybe in other motorsports, but also allegedly the range of vehicles you can drive).
In contrast, if I am proficient in emacs I am...proficient in emacs. I edit code in a manner that is visually impressive to maybe three persons in the CS department. I'd have an ever-so-slightly deeper connection to RMS than your average CRUD-slinger. I am out of advantages to enumerate and I'm trying very hard.
Maybe text editors are about as similar to cars as apples are to buildings.
F1 race cars are literally the least flexible cars available. They are designed for exactly one type of racing and there is hardly anything you are allowed to configure the way you want. There are cars with higher top speeds than F1 cars, and cars that accelerate faster. A $2k second hand Honda Civic will beat the crap out of an F1 car around a gravel track. F1 cars aren't even the fastest design for racing on F1 race tracks. F1 cars are only good for one thing, and that is winning F1 races.
I found this a bit confusing. Why is that, do F1 races have a speed limit? I openly admit my ignorance about F1.
Your analogy works too, but it's parallel.
In reality though, Emacs is a subpar editor for both everyday and specialized tasks that's fallen into obscurity as its maintainers refuse to implement anything that would make it keep up the pace with superior editors.
Until your Emacs process is hung again, waiting for IO, or can't process a "jump to definition", or chokes on a file with extremely long lines, or the stitched-together macOS dark mode switcher daemon has crashed, ad infinitum.
Yes, it's a race car, but from 1987, and in total disrepair.
The massive flaw in your analogy being that Emacs has more to do with an old and crumbling collection racing car than a F1. Its users constantly need to tinker it to make it somewhat run like a normal car. It’s still slower and less ergonomic but they are blinded by their love and habit to its obvious flaws.
The amount of IDE and editors that just work well with little customisation and have great refactoring features is now so high, it leaves little place for emacs.
And there are roughly 20 F1 drivers on the planet at a given time, are you suggesting the total audience for emacs is about 20?
Some of us want a car that any of our relatives can just jump in and use.
Both goals make sense.
Yes, the Jeep Wrangler will topple over while trying to go through a ravine (which no other mass-produced four-wheeled vehicle would ever be capable of going through), but that's what after-market rollcages are for.
An F1-analogue editor would be incredibly fragile, narrowly focused, and demand a huge amount of maintenance.
For the last, both this HN discussion and IIRC TFA offer widely varying estimates as to how much people need to tinker with their configuration files. For the others, only being able to run on one kind of track (absolutely flat ones) would be for an editor to only work for one programming language; spinning and flying into bits at the slightest touch would be for the editor to crash as soon as you type in bad syntax or misspell a variable name; and needing the engine rebuilt after each race and replaced every third or fourth would be... I'm not sure, needing to update to a new version of your editor every three or four weeks?
If Emacs is like any sort of car, it's certainly not an F1 one.
If we want to assign a car to emacs, it's more like a Toyota Tacoma, with no body. Rugged, flexible, some basic building blocks that function out of the box.
So going by results, if emacs was so awesome and if it gave such a huge boost, then we would see those results, and it would be trivial to convince anyone to switch to it.
Personally, I don't see editing text as a bottleneck for developer productivity. The vast majority of time is spent reading code, thinking about code, stepping through/debugging code, reading specs, etc. Yes, emacs can do those things to (as can any system that supports plugins), but my point is that we don't see a 'competitive edge' where all the most productive developers use X. What we see is productive developers using a wide variety of tools. Going back to your F1 analogy, there isn't a single sedan winning F1 races.
Rather than an F1 race car, maybe the analogy would be better made to one of those backhoe/front loader combos. While it won't do simple operations like getting you from point 'A' to point 'B' as quickly, you can do more once you get there as compared to the family sedan. Of course, once you do get there you have to invest substantial time learning how to use the backhoe, the front loader, how not to tip it over, how not to inadvertently break stuff with it, etc. But once you've taken all that time and practiced it enough... you can do quite a lot.
That metaphor feels very much more Emacs like.
With regards to obsolete and outdated - I started using vi and emacs back in 1989 (I currently use vi more). The keybindings and such I learned back then are still relevant.
In my day job, I mostly program Android. Before 2014, I programmed with Eclipse and an Android plugin, which is what Google suggested. Then Android Studio was released, which is what Google suggested. As I haven't used Eclipse at all since around 2014-2015, Eclipse, to me any how, has become "obsolete/outdated". Yet I'm still using vi (and emacs) as I have since the 1980s. They have not become outdated, I still use them as I always have.
Most people want a newer car, that's picked up the improvements in safety and performance from the last 30 years.
The greatest threat to Emacs, as to any other fairly well-liked open-source editor, is a paradigm change in how software gets built or run, not whether it has 7% or 9% mindshare.
The modern paradigm of running npm/brew/composer/webpack/whatever gimcrack tool that gets shoehorned into the build process has led a lot of people to the VSCode-ish side of things that make integrating these things easy. emacs tends to look like a well-appointed workshop with lots of good, sharp tools and a stack of raw lumber, whereas VSCode looks like a finished Chesterfield. It takes a certain sort of person to prefer the workshop over the finished piece, and I'm not sure you could ever change that.
> The greatest threat to Emacs, [..] is a paradigm change in how software gets built or run
Is a little to far into scify land.
First it requires software to no longer be text based, and then it requires virtually all software to switch to this non-text based solution.
In that world a single user can keep Emacs up to date and compatible by asking our AI overlords to do it.
First, Emacs has the best Vim compatibility I've seen outside of Vim itself. Visual Studio is probably "good enough" for me on this with the vim plugin, but that 5% difference in compatibility makes a difference in practice.
But the largest reason I can't get away from Emacs is Ivy/Counsel. Being able to fuzzy search on the current file or entire project, see results, jump around to each one to see context, make changes to the results in an occur buffer to selectively mass edit search results...all of that I just haven't found a replacement for. Search/replace just doesn't cut it.
So effectively if I move to another editor, my code navigation time increases by 5-10x. Things like better autocomplete might fill that gap, but just even understanding how things go together is so much more difficult when you're fighting with your editor.
Add on other things like org-roam, buffer fuzzy searching in Ivy, fasd tie-in, the customization options, etc, and Emacs is just an amazing experience. There are definitely things I would change, like inline debugging (which I use VS Code for instead), setting up languages and autocomplete, etc. Getting things just right takes a long time for a new language.
Lua as the default configuration language makes things simple to configure as well.
Having said all that...if someone told me [insert-text-editor] had everything I would want I would probably check it out and go home to vim (but I do enjoy learning about new stuff and features).
[0] https://github.com/nvim-telescope/telescope.nvim
[1] https://www.youtube.com/watch?v=65AVwHZflsU -- demo video
[2] https://github.com/nvim-telescope/telescope.nvim#vim-pickers
[3] https://www.lunarvim.org/