Emacs is certainly "dying" in the sense that I don't see any undergraduates using it. 20 years ago students were mostly split between vim and emacs. As time went by, both have dropped. Vim has picked up again in the last 8 years or so, helped by neovim, but I don't think I've seen an undergraduate (out of 100 students per year) using Emacs for about 5 years.
My belief (from listening to students) is that vim using highly non-standard keys is seeing as a worth-while tradeoff for the extra editing power it provides. With emacs, it's not clear there is any advantage to emacs not using the standard ctrl+x,c,v,n,s,f, etc.
Vim's model of modality and mnemonics is a beautiful, powerful, amazing paradigm. Here's the thing though - there's no such thing as the "vim-mode". None of the IDEs and editors like IntelliJ, VSCode, XCode, Android Studio, Sublime, etc., can properly emulate Vim navigation. The one exception is Emacs.
Pretty much every other IDE fails to comprehensively 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.
Just that alone speaks volumes about the extensibility of Emacs.
While Evil-mode (the Extensible VI Layer for Emacs) obviously is not the most important or even built-in feature of Emacs, as a nerd and a computer programmer, if I discovered that there's a civilian plane that can perform a vertical landing, yet never actually needs to use it, I would still love that model over any other planes, even if the feature is purely accidental. The fact that it can do so alone would be great evidence of amazing engineering.
And as a die-hard Vimmer, one day I had a revelation - I realized that Emacs vims better than Vim and Neovim. While also opening possibilities for many, many other things.
> None of the IDEs and editors like IntelliJ, VSCode, XCode, Android Studio, Sublime, etc., can properly emulate Vim navigation.
I'm been a vi/vim user for 40 years, and VSCode's emulation is good enough for me. Given the number of installs I'd say it's good enough for a lot of people.
But I still go back to vim over vscode. That's because VSCode can be an absolute dog. I've seen it take 10 seconds to respond to a keystroke on a Thankpad-X1 with 32GB of RAM. The syntax error highlighting can take minutes to catch up, "go to definition" fines up a spinner for so long it's literally faster to find it yourself. Meanwhile, vim is instantaneous at just about everything. It may not be pretty or as helpful, but when code is flowing from the fingers it gets out of the way and lets it happen.
Oh come on. It doesn't even "vimify" things in other than the file editor, which basically is the same for every app with vim emulation. Vim feels amazing in Neovim. In other IDEs, if you aspire to be an "advanced vimmer", you'd quickly hit a bunch of limitations. The most significant one is that you cannot vimify things in every tool window
In Emacs, you can "Evilify" pretty much any buffer, allowing vim-navigation use in Dired and Magit, and anywhere else (even in the minibuffer). You also have the ability to extend any command, adding extra features like custom ex-commands, for instance. As far as I know, such functionality is not even available in vanilla Vim. Hoping for similar features in IDEAVim or the VSCode Vim plugins is wishful thinking.
Besides, even with barebones, after installing Vim plugin in VSCode (I tried multiple) there's some noticeable latency, while my Emacs instance, with over 300 added plugins still feels zippy.
To me the popularity of vim is also due that it's a small and fast editor to be used in the cli with more featires than nano, while emacs mostly is a gui application. This makes it ideal to edit configuration files or small scripts on a server. I use it mostly for this reason, and my coworkers use it for the same reason, while I use vscode for programming.
This trope is older than I am. And the standard answer is equally old: you wouldn't use the remote server's emacs, you would connect to the remote server from inside your own local emacs.
I share that impression. Emacs only lives on as an imaginary yang to vim. vim has found a certain niche as a skill that functions through a text mode ssh because when you use it as a minimalistic editor that's exactly what it is. Emacs on the other hand keeps shouting at you "if you don't use me like a fully fledged IDE you're doing it wrong" and so people who have their IDE slot already taken will naturally gravitate to vim if nano is not enough. Some of those might eventually switch you vim completely, but it's also happy in the middle ground situation. It certainly comes as a surprise, but it turns out that vim offers a more inviting on-ramp than emacs.
> Emacs on the other hand keeps shouting at you "if you don't use me like a fully fledged IDE you're doing it wrong"
People want to do everything in Emacs not because it forces them to, but because it allows you to do a bunch of things in a very cohesive manner. Trust me, taking notes while reading a PDF, jumping from a specific page to your notes and vice-versa, linking a YouTube video to the specific note, extracting subtitles for that video, feeding the entire transcription to ChatGPT to generate the summary for that vid, then composing Anki card content and pushing it to your Anki collection for that subject. Or even doing something utterly stupid like forcing Google Translate to expand numbers to their written form:https://www.reddit.com/r/emacs/comments/1aey0eo/they_are_sur.... That all, is extremely empowering and liberating.
People often say: "These workflows you describe sound amazing, but I don't see myself doing them." Before Emacs, I wouldn't have considered doing things like that in a single app. I would have tried finding a specialized app for each thing. Becoming an Emacs hacker changes your mindset. Why settle for anything else when I can run it with a simple keystroke? And it's not just about saving time or not losing focus. It's just inexplicable fun to have refined control over text. Any kind of text.
I thought _emacs_ had the standard shortcuts and vim was weird. After all, I can ctrl-a (beginning of line), ctrl-e (end of line), modifier-b (back one word), etc. all in my terminal, as well as most non-Windows desktops (including MacOS).
They were using it because they were forced to. I remember all the complaints people had why they couldn't use a real operating system and text editor for their code when they first showed up to classes.
if you do simple edit / copypaste / save, emacs has no value
if you do anything complex, it starts to have some, just like lisps in a way
now i can understand why emacs is not used in the days of vscode and jupiter notebooks, but weirdly enough, the visible emacs community is growing (more confs, more attendance), which honestly makes me wonder why
I don't know (or care) if Emacs is dying, but that is a point suggesting death is on the way.
We have in Emacs an editor where the default keybindings aren't great (literally designed for keyboards that no longer exist). The configuration language is Elisp, which is not a great language (being a lisp is great, but by lisp standards it is eclipsed by Common lisp or Clojure depending on personal preferences). The overall feel of the editor with lots of extensions is a bit patchwork and unprofessional. The model of editing text is a relic from a time when multiple threads didn't exist and window managers were not yet a thing.
I love Emacs to death and it isn't leaving my hands until they are cold and dead; but for the life of me I don't see why anyone should invest the time to learn Emacs. The greater programming community would be better off letting it die then rebuilding something similar with different defaults.
All Emacs is good for is as a platform for building a completely different text editor out of extensions.
I've walked around editors / IDE etc and the flaws of emacs still don't overcome the benefits. I'd be curious to see some deep improvements though, but it won't matter much if not.
They can't make effective decisions about the modes without understanding base Emacs. And base Emacs is pretty awful.
New users are better off using a text editor with sane defaults. Then they don't even need to build their own text editor. A lot of what makes Emacs good to use are modes that bring it up to parity with things like vim and Visual Studio.
No, a lot of what makes idiots quit emacs is trying to bring it up to parity with vim and Visual Studio. What makes emacs great are modes like tramp, dried, magit and org-mode which turn it into a portable operating system from the year 3000.
I would argue it is. Not because of Emacs itself though, but because they are the default gnu readline keybindings.
This means that by learning these, one can use them in almost every application on every platform that has a "text input field" type component. Browsers, Adobe software, most native macOS software, any REPL such as python, etc. Even in the shell, ones workflow is just so much better after learning these. (Yes, I am aware that vim input mode exists).
But then again, that's as much of emacs that I bothered to learn...
I do see emacs often used in competitive programming, mostly by undergrads too. But of course, that is already a very small subset of all undergrads.
The same has been said about VS code. I.e it is just a husk that you need to modify to something useful. This makes them useless to many. Sane defaults is important and should be there.
This is going to be one of those things where everyone shouts and stuff so I'm just pre-emptively putting it out there that this is only my experience and I can only speak for myself.
But in my entire life, now in my 40s, I have met exactly one person who used emacs enough that I knew/they told me. I don't really have a dog in the fight between vi and emacs. Back when editing your xf86.cfg was something you had to do fairly regularly to get your gui back after looking at it the wrong way or saying something that offended it I would use vi just because the barrier to 'typing some words and saving the file' is lower, but I have no great appreciation for it either. I feel like both are... suitable for the limited environment they had, useful in a pinch, but everyone much prefers using something more intuitive.
In the nineties, emacs used to be the #1 text editor. On Unix. Which reached a tiny fraction of a percent of programmers. In that community, it felt overwhelmingly popular (competing with vi who was in a close second).
Ironically, of the two, emacs was the user-friendly alternative.
Today, Linux is the most popular operating system on the planet (if you don't believe me, count up those Android phones, network routers, and embedded devices). Even so, emacs runs on Windows and MacOS. That market is many orders of magnitude bigger. It has a tiny fraction of a percent penetration in the market of "devices with a CPU." So it feels very niche.
There are no figures I'm aware of for number of users, but it's not at all clear to me how to compare:
(tiny market) · (large percentage)
versus
(huge market) · (tiny percentage)
Even as estimates. Qualitatively, it feels different. The level of "emacs community" has gone down, but "community" isn't about quantity, and can be reached with a dozen tight-nit users.
After 25 years of coding primarily in emacs, I switched mainly to VS Code for larger, more complicated projects last year. I did it mainly because it eases navigation through large code bases and because the visual debugger is so easy to use.
I still use emacs in the terminal for scripting and for smaller coding projects, for anything over SSH, and for blogging and fiction writing. It's a distraction-free editor that has very powerful features when you need them, but doesn't shove them in your face. It's also nice to be able to do everything with the keyboard and not have to keep reaching for the mouse.
Same here, I came into massive project from embeded and driver dev where Vim with plugins was better for development. Instant start on everything that can run linux. Minimal hustle.
However when you debug race conditions in app with 100s of threads in containerized environment, the limitations of cli starts to show.
As with everything there is no silver bullets and its a good skill to be able to pick right tool for the right task
I use VSCode sometimes to click through a new codebase, but its memory consumption can be hard to swallow particularly when various LSP servers are running (looking at you terraform-ls).
I think web tools will replace this in time they are just so convenient, I have setup custom reference tools for code bases. These are simple to setup on a server or on you own desktop, but even with a seemingly perfect Nix install dependcies might fail.
One source of stats is the 2023 Annual Rust Survey. The question on text editors allowed multiple responses (so percentages naturally don't add up to 100%), but 5.5% of respondents reported using Emacs for Rust vs ~30% for Vim/Neovim, vs ~61% for VS Code. I was shocked that Emacs and Vim weren't closer. https://blog.rust-lang.org/2024/02/19/2023-Rust-Annual-Surve...
Obviously, it's possible this is a quirk of the Rust community. Though the Go survey shows similarly small Emacs usage numbers https://go.dev/blog/survey2023-h2-results (3% Emacs vs 16% Vim/Neovim).
Why would emacs be larger? It’s anecdotal, but I’ve gone thru my entire life (I’m 25) without ever seeing it installed on a machine I have used or mentioned in any of the learning materials, when I was younger I only heard it as a flame war topic.
> I was shocked that Emacs and Vim weren't closer.
I don't really find this surprising. VS Code is just very easy to use and full featured without spending much time on configuration. It took me a while but I had to admit I was just making my life harder by using vim instead of vs code
Yes that's what I meant. Just an assumption I'd had, perhaps the joking about Emacs vs Vim preference in programmers made me assume the groups were of similar size.
I came to the game at the tail end of the Vim-vs-Emacs war.
People pick up a particular editor not because it's always objectively better, but rather because it was the only available thing they liked at a certain point in time. Then, over the years, Newton’s first law takes over.
Since I stepped into the industry only a few years ago, I didn’t see the appeal of spending so much time configuring a tool. So, neither Vim nor Emacs seemed like a sensible choice. I went with VSCode and forgot when was the last time I had to configure something.
Now that we're seeing new editors like Zed making some splash, I'm exhibiting the same bias for VSCode that older programmers show for Vim or Emacs.
> People pick up a particular editor not because it's always objectively better, but rather because it was the only available thing they liked at a certain point in time.
I've been programming for I dunno, over twenty years I think. I tried many different editors, tools, IDEs, specialized apps. I kept moving around. Started from Turbo Pascal and Borland tools on DOS, then continued using Borland Tools in Windows. Borland was fucking huge at that time, to the point (and I kid you not) that one of my college mates told me: "dude, I just learned that the first name of Pascal (the mathematician) was Blaise...I thought all this time that his name was Borland... That's how the company got its name, I thought..." I mean, he was not kidding, he seemed genuinely confused.
Later I used Visual Studio (not VSCode). That was some almost absurdly heavy beast. It could die in the midst of compiling a project. The versions were so incompatible, often you couldn't even take a project created in one version of Studio and simply open it in the newer version. And so, often you'd have to have multiple instances of that thing open. Visual Studio had everything, including something called TFS (Team Foundation Server), that had tons of features for project management and some other crap, but for some reason most teams only used arguably the crappiest feature of TFS - the version control. It was quite some stupid shit and made me mad almost daily. When I discovered Git and learned it a bit, I stopped using stupid TFS, but I couldn't convince my team to switch, so I had to use a bridge to push my things to TFS. While I was learning Git, I accidentally stumbled upon Vim, and of course the first time seeing it I simply couldn't figure it out. I cursed out, and found a way to set a different editor as a default one. But shortly after, it made me thinking: "why would Git, such a clever and awesome tool choose to use this weird Vim-thing as a default editor?" I got intrigued and started learning Vim. After a month of hating myself, I suddenly realized that I no longer know how type in my editor like I used to. From that point on, whatever editor or IDE I would use, I invariably used with a vim-plugin. And If the tool didn't have one, I would just refuse using it.
Then followed Sublime, Atom and finally Jetbrains products - WebStorm, Pycharm, RubyMine, IntelliJ Ultimate. I stayed with IntelliJ the longest - around seven years. I explored every single imaginable documented and not so-well documented feature of it. I had a huge poster on my wall of a printed cheatsheet. I discovered, reported, discussed and followed tons of bugs. Funny, sometimes, even now, I still get updates for things I filed back in 2012-2014. I felt like Andrey Vlasovskikh (at that time) maintainer of IdeaVim plugin had become my family. I loved IntelliJ. It was great. It had everything I wanted. If I ever felt the urge of thinking that I wanted something that it didn't have, I convinced myself to want less. For a relatively short period I had to use XCode, and OMG, compared to it, IntelliJ felt like a godsend.
And one day, I took a flight from New York to San Francisco. My next-seat guy opened a laptop and started typing things in Emacs. I just couldn't help it. First, I pretended to be asleep and kept peeking. After forty minutes of that lame game, I simply couldn't hold it anymore and started asking questions. Until that point in my career, I haven't seen anyone coding like that guy - without googling things; without StackOverlfow; without constantly jumping between documentation, terminal console, utility apps, and the editor. It was all in one place. It was clean and strangely ascetic - no toolbars or menu, no icons, no progress bars, no multitude of numbers indicating different things. Another thing that fascinated me was how easily he manipulated window panes using only the keyboard. Clearly, he was "in the zone" - it seemed as if he had zero context switching. That was very different from how I wrote code and most of my colleagues as well. And he wasn't using some esoteric, little-known language. He was writing in Golang. I didn't know it then; still, it wasn't some completely alien thing to me. Yet some things I saw almost mesmerized me.
That flight, though, wasn't enough to inspire me to try Emacs. Soon enough, I forgot about it. Three months later, I made a jump in my career. At my new job, there were a handful of Emacs users. I learned many new things from them (unrelated to Emacs). And that's when I installed Emacs on my machine for the first time. It still would take me another two years to transition. At some point, I realized that I have multiple things - IntelliJ, Vim, Emacs and Sublime (or Atom) open all the time, and I decided that I needed to start making cuts. My first fear was that I woudn't be able to vim as efficiently in Emacs as I used to. I was wrong. My second and major fear was that if I invest myself in learning Emacs, one day I inevitably find something that's not possible in Emacs, but still doable in IntelliJ and I would feel handicapped and would have to give up and move back and feel bitter for wasting my time. And once again, I proved to be wrong.
Today, I cannot imagine doing any meaningful work without Emacs. From time to time I open AndroidStudio or VSCode and try to figure out some basic workflow there, but always move back to Emacs. It is hard to explain what makes Emacs such an irreplaceable tool for me - I'd have to write a book. But I do remember one of the first things that won me over. Search. Emacs has superior search I have not seen in any other tool. It offers too many different ways for searching things - locally, remotely, recursively, partially, contextually, dynamically, etc. With filtering the results and sifting through and editing at the same time.
I dunno, I feel I pick Emacs over and over specifically because it is objectively better. For me. Someone else may have different opinion and their experience may not be the same, but I swear, no other editor or IDE makes me feel content. And not because I have little patience to learn new tools. I do very much like tinkering around my tools. And I do firmly believe that knowing my instrument well is not a part of my job. It is my job.
I never knew how popular Emacs is before going into finance (which definitely tends to attract older programmers on average). I'd say it's more popular than Vim in my environment, which is surprising. It definitely has the air of the ultimate "erudite" text editor.
I'll stick with (neo)vim, though, I don't see the time investment to learn Emacs and build up a config as worth it + neovim with Lua and LSP works just fine and is rather easy to configure.
For what it's worth, setting up a language with the LSP is dead simple in a .emacs file, editing my config is something I enjoy a lot with emacs, make a change, M-x load-file .emacs, boom, face highlighting, autocomplete, pretty much everything and more, surprisingly it ran better than when I tried VScode
> One of the things I have found throughout my career is that serious programmers pretty much stick to one of two (arguably three) editors: Emacs or Vi(m), and on OS X, TextMate.
Who is complaining that software gets worse and that quality is dropping? And, more importantly, do they offer any data to back that up?
Or do they, like I do, anecdotally complain that slack eats all my memory to do stuff that we could do with IRC decades ago? (Which is provably wrong when I think about it for more than a few minutes)
I couldn't do that from memory, not something that is needed 99.99% of the time. Just use a standard library.
I would agree that people should be able to understand what type of algorithm to use in different situations.
Most code I've seen isnt very good. The degree the author has (or the absence of one) has not been a useful predictor of code quality in my experience.
I guess me and my friends who are all programmers with 20+ years of experience working across multiple industries in senior roles are not serious programmers.
Emacs is not dying, but I don't know if it is well. I feel that for non-lisp developers it is only the last choice. Ecosystem is split between eglot and LSP, so you have to choose between debugger availability and performance for many languages. You have to do a lot of work to stop emacs opening buffers left and right on every occasion. Load times and micro-stutters make it a hard sell.
Some amazing work was done in last years with jit compilation, but also some, imo bad decisions were done with the way treesitter was introduced. I love the introspection and self-documentation of emacs, but I just cannot justify using it after neovim, which is very sleek with telescope and mason, easier to configure, fast and just aesthetically more pleasant, to be honest. Maybe if I would not need editors for programming, I would be more interested in org-mode, but on itself it is not enough to keep me in emacs.
I think the corollary to this question pattern is always: "And if yes, who cares?" If the software in question is open source, the ones using it will still have enough access to it even if it were dying. The ones not using it don't want it anyway and chose one of the many other options.
More diversity amongst editors is important. Given Microsoft’s track record of EEE, one wonders what they can do with vscode. Maybe one day it will only support GitHub, maybe code sharing gets picked up and is only available on vscode, forcing you to use it because everyone else.
It’s never a good thing that Microsoft has majority market share.
Interesting comments, mostly from people who have been around the block a few times. Personally I'm young and I just picked up Emacs a few years ago. I'm still unashamedly in the evangelical phase, wanting to share it with everyone I meet. It's literally a gift from all the good deities combined. But I can see why it's not more popular. You need to be a programmer to make it even halfway usable. That's its power and its curse.
Personally I think GNU Emacs is a dead end. If Emacs is to live on it needs to be rewritten from the ground up in Common Lisp, it needs to be multithreaded, and it needs to have default keybinds that target the average computer user; us wizards can change them with ease. I think Lem looks quite promising.
When I started using emacs around 10 years ago, it felt pretty stale and I had the impression that it hadn't been updated much in a long time.
Now it feels like it's being very actively maintained. There are regularly new modern features being introduced.
The fluid keyboard only interface (using doom emacs) is something I can't live without now. I have tried and failed to recreate the experience in VSCode.
It is mostly the nicely integrated defaults of doom emacs. Browsing files, code completion suggestions, code references and search results can mostly be achieved with the same convenient keyboard shortcuts, the exceptions are very frustrating.
There are quite a few packages involved but they are mostly managed and configured by doom. The default keyboard bindings play a huge role in the fluidity as well.
Even if it's not dying no one there cares about the user experience so stagnation is inevitable. Just compare the out of box experience for both VSCode and Emacs and it is no surprise why VSCode is more popular. Take a simple feature like showing different files that are open in tabs. Emacs' solution to switching between buffers is harder to use if you want to go between different files you have open. How many years do you think it will take before Emacs has tabs for different files open by default? A ubiquitous feature of text editors. This is what leads people to think Emacs is dead. It's stuck in a design from decades ago and the project is unable to evolve. It is only able to slowly iterate upon itself.
> Just compare the out of box experience for both VSCode and Emacs
One thing I learned after using, designing, and building tons of different software products - there's often a strong correlation between something that is seemingly complex and difficult to start with and then gained simplicity later. Conversely, something that is very easy to get into often becomes extremely difficult to use later, slowing you down with a bunch of arbitrary drawbacks simply because it was never designed for "advanced power users" to begin with. Road to simplicity is rarely a straightforward and effortless journey.
For many people, the most - it's just easier to choose "fast food" of features, instead of painstakingly figuring out how to "make your own burger". And they never build a mental model of "being a cook", they just learn to consume what they've given. There's nothing wrong with that. Except that they often confuse the "there's no other way" with the illusion of "it just works".
Applying to the concrete example you're using, it would take me maybe just 10-15 minutes to whip up an Elisp function that would open each file in its own tab. I don't do that because there are many more empowering and productive ways than having each file in its own tab. Like Einstein one said: "What is right is not always popular and what is popular is not always right".
User experience is highly relative. To me magit is peak UX, above many many tools.. but to some it's utter sh8t and they want vscode (even though they are the one sweating and ranting everytime they get confused).
I agree that magit has relatively good UX compared to the rest of Emacs, but it is held back by Emacs' abhorrent performance. Magit however is not bundled with Emacs so I can not attribute its UX quality to the base Emacs editor.
I do think of you did an actual user study you would find that it should be using more GUI elements to expose operations instead of keybindings
Except on windows I don't recall any performance issues that were not due to repo size.
Magit is an extension of the old emacs outline mode, it inherits all the ergonomics culture around it (tab to fold, C-n/C-p for skipping, C-c C-c to validate..., k to kill). User studies don't apply here, it's too complex (due to the inheritance mentionned above). As I said, I have colleagues using other tools, they're slower and angrier, even with more buttons, which is somehow part of emacs culture.. don't create more widgets than necessary. And I'd argue it's irrelevant to good HCI for non mainstream duties.
You can't compare fairly since people will cluster around what they consider right. Even though, as I can witness daily, they suffer more, take more time than the 'obscure emacs thing'. So many git interfaces add more weight, lag, random iconography and terminology. But it taps into people love for shiny, it seems an exciting new tool with all bells and whistles when in fact, it disrupt your flow more, adds layers of confusion and costs more ultimately.
Fair point about massive hunk set causing lag, it's plausible.
My expectation as a user is that the editor should never freeze. It should render at my monitor's refresh rate. What I experienced sometimes with magit is the editor freezing rendering 0 frames for 10s of seconds. It does have to do with Emacs.
Emacs has by far the best the best 'file switching experience' I've ever seen with treemacs, which is a sidebar with multiple projects, each with its file tree. Projects are part of workspaces which you can switch between. The whole thing can be configured with right click menus, or by editing an org file.
Additionally it has not one but two tab modes built-in (tab-line-mode, tab-bar-mode)
Defaults matter and this is just one problem of many that needs to be fixed. It's not okay to ship a bad product because a user can fix it themselves if they really wanted to. Products that work well out of the box will have an advantage over those that don't.
> It's not okay to ship a bad product because a user can fix it themselves
I think you are confused about the definition of Emacs as a product. As stated in its documentation: "Emacs is the advanced, extensible, customizable, self-documenting editor." It is designed for advanced power users who are willing to extend and customize it. What you consider to be "must-have defaults" is as arbitrary and controversial as having an option to use vim keybindings or some popular dark theme out of the box. If you're saying that someone can't use Emacs because it doesn't open each file on a dedicated tab, maybe that's not Emacs's target audience?
Anyway, I do remember my younger self. I, too, was raging about this specific thing. I didn't understand "the philosophy of buffers," and people kept telling me "trust me, you don't need the tabs..." and I hated that. But I promise you, and please trust me, you really do not need the tabs. I've been there, I tried disproving everyone who told me that, and I admit that I was wrong.
>It is designed for advanced power users who are willing to extend and customize it.
That doesn't mean the default experience should be bad. Why not start with a good experience and let users build on top of that.
>What you consider to be "must-have defaults" is as arbitrary and controversial as having an option to use vim keybindings or some popular dark theme out of the box.
Which is why it is important to get feedback from real users. Get a random person off the street to use Emacs and see if they have an easier time with tabs. Repeat with intermediate and advanced Emacs users. See what works and what doesn't.
>If you're saying that someone can't use Emacs because it doesn't open each file on a dedicated tab, maybe that's not Emacs's target audience?
It's not that it's impossible it would be that users have a harder time to accomplish what they want.
>maybe that's not Emacs's target audience?
This is the kind of needless gatekeeping that will lead to Emacs death.
> This is the kind of needless gatekeeping that will lead to Emacs death.
This isn't "gatekeeping". What are you talking about? I expressed my personal opinion about one aspect of the default interface. I'm not an Emacs maintainer, RMS' cousin, Zaretskii's dog sitter, or director of FSF, I don't "call the shots".
Emacs is completely free to use, distribute and contribute to. Go ahead then, come up with convincing arguments, compose a proposal and write to the emacs-devel mailing list. Maybe, after all you are truly a bright-minded visionary and those dorks that been maintaining Emacs for over 45 years just don't know anything?
> it is important to get feedback from real users
Nobody is stopping you from giving such feedback. I don't think there were many cases in history where technological breakthroughs happened due to random people arguing about a subject on a forum like HN or Reddit. You have complete freedom to do something about it if you passionately believe in it.
> Emacs' solution to switching between buffers is harder to use if you want to go between different files you have open.
Are you sure?
If I am on foo.rs and I want to go to bar.rs all I type is C-x b bar and type Enter and done! I find this way easier than hunting and pecking for my tab in VSCode.
I used Emacs for roughly 30 years. During the last 20 or så of those years I would try to use Eclipse, IntelliJ and other IDEs for a few months every 2-3 years, but none of them stuck. The extra functionality they provided was nice, but as editors they just didn't work for me.
A few years ago it was time to try an IDE again plus I had spent another full working day trying to get Emacs set up properly to program Go. I was really tired of my setup breaking all the time and that adding support for specific languages took so much time. So I tried Visual Studio Code.
I'm not sure why, but for some reason, this time it stuck. I started using VSC for writing Go code. I also write a bit of C/C++, but even on VSC that's still a pain in the ass. More because C/C++ tooling never got cleaned up and the only thing it has really accomplished over the past two decades is for the tooling to grow less usable, more complex and more infuriating. Not even the relatively high quality of VSC extensions seems to be able to fix that.
I find it really hard to articulate what needs doing to "fix" Emacs, but I think part of the problem is that there's so few people doing real work on maintaining and developing Emacs - and even less coordinated work on writing extensions for Emacs. Lars Magne is making a heroic effort to close bugs and get Emacs into shape, but there just doesn't seem to be a large enough community to coordinate and streamline support for various languages. It's a mess.
I really hope Emacs does not die. I spent most of my professional career writing code in Emacs. I like Emacs. But it needs people who can evolve its support for various languages and it needs people who can do so in a more coordinated fashion.
One thing I think Emacs could borrow from VSC is the concept of synchronizing configuration across machines. That's something that should really be built into Emacs and I think that it may be one of those things one could use to drive evolution because it would force maintainers of extensions to think about streamlining.
Emacs could be much more alive if it actually had good documentation.
Leaning Vim is also painful, but compared to learning Emacs it's a breeze.
I've tried learning both. I'm currently a Neovim user, and every now and then I revisit Emacs in hope of learning how to unlock its (alleged) powers. I give up every time because it is just too frustrating to even get to the point where I can smoothly edit a .c file.
I think Emacs has excellent docs tbh, the docs page online are usually very good and within Emacs as well as in `info-mode`. What is sometimes confusing though is the large amount of jargon and details you need to know to get in a place where it works as excepted. Half because Emacs was created before modern conventions in naming stuff but also because it's a complex piece of software (or at least it has the potential for great complexity).
Great trolling. Emacs has remarkably good documentation. You can look up the documentation of any function and command. You are not even allowed to ship an extension (package) for Emacs to any major package repository without properly linting and ensuring that every single publicly used function has a proper docstring, where each argument is documented, and each docstring is properly formatted and punctuation is in place.
> I give up every time because it is just too frustrating
It's quite alright. I gave up multiple times before finally moving over. The biggest revelation I had is that instead of trying to "understand the features" of the editor, I needed to start learning Emacs Lisp and how to properly write it. How standard hooks work, how to use --debug-init to analyze what's being loaded; how edebug and built-in profiler work, how to investigate exactly what happens when I press a key, etc. Just be patient, Emacs is a beast, nobody ever tamed it in one day. It takes time and patience.
I didn't mean to troll, but I definitely could've phrased it better.
I don't mean Emacs has bad documentation - in fact, as one of the oldest GNU packages around (and RMS' own pet project), it probably has the most comprehensive documentation around.
But, as other people have mentioned, it's too damn large. Eight chapters until I get to the basic editing commands! And that's just the default keybindings - which, according to most Emacs users, suck and need to be changed to your own taste with keyboard macros - which are waiting for you on the eighteenth chapter!
Maybe I'm a youngster spoiled by television and videogames and need to get off your lawn, but having to read eighteen chapters just to get to make my own keyboard mappings is... discouraging. In contrast, learning Vim took me an hour of Vimtutor, then slowly discovering feature by feature when I needed it. It was a much more natural process than all my attempts to learn Emacs.
> In contrast, learning Vim took me an hour of Vimtutor, then slowly discovering feature by feature when I needed it.
My process has been to turn on Evil mode, learn about C-h {k,f,v,m} and M-x customize-group, and then slowly discover features when I needed them. IME this has been quite a natural process too.
> but having to read eighteen chapters just to get to make my own keyboard mappings is...
That's a very disingenuous way of deflecting your lack of motivation for learning Emacs on 18 chapters of documentation. I'm sure you code in some programming language, maybe multiple of them even. I'm sure each such programming language comes with tons of documentation. Do you read the whole language manuals/books before you start doing something useful with it? Or do you just learn the basics and look up what you need as you figure it out?
The basics of Emacs are easily accessible from C-h t and that's the first thing Emacs shows in its welcome screen when you launch it the first time. It takes less time to finish that C-h t tutorial than it takes to learn the basics of a new programming language.
Nobody really reads 18 chapters of documentation before making keyboard mappings. I make keyboard mappings and I read 0 chapters of the documentation. 0. Zero. How? Just like you do anything else in software these days? Looking it up, jumping directly to the documentation I needed to learn how to do key maps.
There's nothing special about doing things in Emacs. You can learn Emacs just the way you learn any programming language. What might be different about learning Rust or Python might be that most people find themselves motivated to learn it so they are motivated enough to look up what they need. But many people are not so motivated to learn what they perceive as merely an editor. If you do not have the motivation to learn Emacs the same way, that's fine. But blaming it on the large documentation does not seem fair.
> Nobody really reads 18 chapters of documentation before making keyboard mappings. I make keyboard mappings and I read 0 chapters of the documentation. 0. Zero. How? Just like you do anything else in software these days? Looking it up, jumping directly to the documentation I needed to learn how to do key maps.
Yes, and that's the approach I used multiple times, the same approach that helped me learn Vim. The learning curve is much steeper, and Vimtutor is much easier to comprehend than the C-t h tutorial.
That's what I tried to say in the first comment, and people attacked me by saying Emacs has awesome documentation. Now you're attacking me, saying that documentation doesn't matter and nobody reads it anyway...
> that documentation doesn't matter and nobody reads it anyway
Did I say that? I don't think so. I said that it is possible to create key mappings without reading 18 chapters of documentation. How? By looking up what we need.
But Emacs users do read the documentation but not necessarily in a linear manner where they must start from Chapter 1 and go all the way to Chapter 18 before they are able to do something. Some people might it read like that. But most people including myself read the parts that matter to us.
> Did I say that? I don't think so. I said that it is possible to create key mappings without reading 18 chapters of documentation. How? By looking up what we need.
And I said that approach didn't work for me. Great that it worked for you, but
I found that looking stuff up for Vim was much easier than looking up stuff for Emacs. Which is what I basically said in the first comment and explained several times in this comment thread.
It might be a bubble I've been pulled in long ago. But I get a lot more content in general on vim/nvim.
I've tried a few times to move to emacs. Partly FOMO (I might be missing out, by sticking with vim/nvim). But found it hard to find good lectures, articles, beginners guides, and YouTubers on emacs. At least not as good, frequent and omnipresent as such content for vim.
I might've searched wrong. I'm probably biased, and quite certainly in a filter bubble. But the accessibility of good, modern content on vim/nvim is what made me decide to just stay there.
Not sure what you mean by Emacs needing better documentation — IME it is exemplary of particularly good documentation + introspection, integrated well with the editor.
Maybe it's too dry for todays culture. You can see numerous people asking for a specific way to communicate: clear single page of features, live tutorials etc
I agree that emacs comes with almost all you need to understand it, but there's one inherent flaw: it's large. It's a joke in the community that nobody is immune to a late "wait, emacs can do that ? I've been using it for N decades and I had no idea.."
Content discovery is somewhat hard, especially in the beginning when you don't know enough of the vocabulary and capabilities to easily find what you want. Ironically, it's at that time in your journey learning how Emacs works, that you need the discovering capabilities the most.
True. But there are a few paradoxes. Back in the days there was not a log to learn.. limited internet, basic html pages. I think people asking for too much is also backward. Good concepts don't come easy in a way. ... I guess there's a balance.
One thing that I wondered is how to make the manual more lispy/repl oriented.
That's fair, I think the style is too dry sometimes but now that I've used Emacs for some time (3 years?) I just look into the pkg docs when I need something, which is rare.
Emacs has very good documentation. It's just that most people nowadays can't read, and if they can read, their attention span is too short for long form content.
You bring up a good point about Vim though. Because Vim has much fewer features, its docs are comparatively shorter and thus more accessible for people nowadays.
"I don’t have figures at hand but it’s my impression that Emacs development and the introduction of major new features has accelerated lately. Regardless, it’s clearly not the case that development has slowed or stalled."
For such a post, it'd be much nicer to have some statistics. It does come around as a post by some heavy user preaching that everything is fine and well but that's just a subjective view from a bubble.
How many commits did emacs have over the last ~10 years?
How many updates and packages in ELPA l/MELPA over the last years?
I find it hard to believe that development has not stagnated a bit in times of all the new editors and lots of young new developers not having touched a terminal and growing up on full fledged IDEs.
I'm saying that as someone liking emacs (I do occasionally use it), but using sublime text and intellij most of my time.
I find emacs an incredible piece of software and which for emacs to stay around!
One also has to consider other factors. Despite the evolution of the core of Emacs not being impressive and possibly even stagnating, it is remarkable how many external packages are available. GitHub alone hosts numerous Emacs Lisp packages, making it the largest body of Lisp code among various Lisp dialects, surpassing Clojure, Common Lisp, Racket, and others. Isn't that impressive? Can someone name a single scripting language used exclusively for configuring a specific editor that is as widely used as Emacs Lisp? Elisp is not a general use programming language; it's not very popular, even among Lisp-hackers; it's not even a great Lisp - it lacks tons of nice features other Lisp dialects had for decades. Yet it is undeniably, the most used Lisp of them all.
How can anyone observe all of this and claim that Emacs is dying?
"there is a lot of X" does not imply "X is increasing". That's what i am pointing out.
There is also a lot of COBOL code. It doesn't mean that COBOL code is increasing.
The Pyramides are huge and impressive. It doesn't mean that more pyramids are built.
>How can anyone observe all of this and claim that Emacs is dying?
Because LISP is also dying. Compare JavaScript vs Emacs Lisp on Google Trends. It doesn't make sense to have an editor exclusively have it's own language instead of reusing a commonly existing one.
Lisp is not "dying". Lisp is constantly evolving and keeps influencing other languages, like Elixir, Julia and others. Even modern Javascript borrowed tons of features from Clojure - a language that many big and small companies succesfully use in production. There are constantly new experimental things happening in Lisp. People building their Hammerspoon, AwesomeWM and Neovim configs with Fennel. Researches keep publishing papers, experimenting in Racket. Even writing books about type theory, which may sound strange since most Lisps are dynamically typed.
You seem to be completely oblivious to the world of modern Lisp, we stopped capitalizing each letter around 1980s. No actual programmer who wrote at least a few Lisp functions would write it today as "LISP".
> It doesn't make sense to have an editor exclusively have it's own language
It may not make sense to you because you don't seem to see the benefits of Lisp. Some extensions for VSCode are written in Clojurescript. Even with obvious overhead, some people see the benefits of choosing that path. While it is possible to go the other route - writing Javascript or Python that emits Lisp, I don't know why anyone would do that. Nobody stopping anyone from writing a Javascript transpiler/compiler that emits Elisp code to configure Emacs. But why would you do that, if Elisp (admittedly not even being the greatest Lisp) is still much more powerful?
> Compare JavaScript vs Emacs Lisp on Google Trends.
What's your point? Javascript is a general-purpose language, it's used in browsers, cloud computing, embedded devices, Game Dev, IoT, Desktop Apps, etc. Elisp is not. Its sole purpose is to be used as a configuration language for one, specific piece of software, that (at least officially) only runs on desktop, and that's it. Yet despite all that, there's quite a lot of it. And people keep writing more. There are few new packages get announced every month or so on r/emacs. That's what I'm saying.
>Lisp is constantly evolving and keeps influencing other languages, like Elixir, Julia and others.
A language doesn't have to be alive to evolve or influence other languages.
>Clojure - a language that many big and small companies succesfully use in production.
This sounds less dead, but Clojure can get away with being semi dead due to its interopt with normal java libraries. No one at my university or the people I have worked with have used Clojure, so it is at most niche.
>People building their Hammerspoon, AwesomeWM and Neovim configs with Fennel.
These are configured with Lua. They do not support Fennel by default from what I can tell.
>Researches keep publishing papers, experimenting in Racket
Researches alone can't make a language reach mass adoption.
>Even writing books about type theory, which may sound strange since most Lisps are dynamically typed.
And such languages produced in those are incredibly niche and likely dead.
>Nobody stopping anyone from writing a Javascript transpiler/compiler that emits Elisp code to configure Emacs.
This misses the point. Javascript is the most well known language among developers. Emacs should be making their extension platform attractive to developers, allowing people to use a language they already know is better than forcing them to learn a new, unfamiliar language.
>>Compare JavaScript vs Emacs Lisp on Google Trends.
>What's your point?
The probability that a developer knows JSON and Javascript is much higher than that developers knowing Elisp, or even a Lisp at all.
Programmers who don't know lisp are dead or dying. But keep calm, they can still be the little-seatwarmer-that-could as team leaders or agile-change-managers. There are lots of unnecessary titels out there in dire need of warm bodies.
I just gave you a few examples of fairly modern Lisps to prove my point that it's not dying. I can list some more, Fennel team just last week shipped an update. Jank is being developed rapidly. Clojure-Dart that allows you to build Flutter apps is also relatively recent addition to the family. Besides Clojurescript and Clojure CLR, there's Babashka to write bash-scripts and NBB to write nodejs scripts in Clojure. There's Clojerl and LFE to write Lisp for ErlangVM. There's Hy - Lisp dialect embedded in Python. There's Lux that targets JVM, JS, Python, Lua and Ruby. There's Joker written in Go. There's Calcit built with Rust. These are all quite vibrant and frequently updated projects, if I start listing projects that have not seen comits in their main branches for a few months, the list would be long.
You're mistaking Lisp for languages like COBOL, Fortran, ObjectiveC, and Pascal. These languages can be considered as dying. I'm hesitant to add PHP to this list because there's still a ton of PHP code out there, and it is still being developed, but it seems that people are finally, slowly moving away from it.
> is better than forcing them to learn a new, unfamiliar language.
But have you actually tried it? Have you ever tried comparing JSON and EDN, JSX/HTML with Hiccup; Javascript coding experience with Clojurescript? I have. I have seen the both worlds. Besides popularity, there's not much that Javascript (in my opinion) can offer to improve simplicity and joy of writing software compared to Clojurescript.
> No one at my university or the people I have worked with have used Clojure
Compared to other programming languages, Clojure is niche, yet actively used in the industry. Big companies like Apple, Walmart, and Cisco have large Clojure codebases. There are also smaller startups like Pitch.com and Shortcut.com that use Clojure. Interesting projects like XTDB, Roam Research, and Loqseq are built with Clojure. Even NASA uses Clojure.
It's easy to be blindsided when you're constantly focused on popular things like JavaScript and Python. But if you actually take the time to look around, you may be surprised to see some interesting things. I promise you, Lisp is far from dying. On the contrary, it just keeps popping back. Maybe one day try learning it, you may find quite a few unexpected gems and finally understand the reasons why it refuses to die.
I used Emacs very intensely a long time ago (to the point of reading mail and pretty much living inside it across various kinds of terminals.
Then I learned vim, and the sheer efficiency of it (yes, I know about evil mode, this was 20 years ago) and never looked back. It’s just everywhere (I can run vim on my iPad via a-Shell, for instance, and even find myself using it inside VS Code’s terminal window…)
I returned to it last year somewhat, because of my constant tinkering with LISP, but these days I see no real point in using it when I have so many GUI options and a better terminal experience with vim.
There are many things that you can do in VSCode and IntelliJ or even Notepad. What most people miss or are completely oblivious to are the unique features of Emacs that are simply not possible anywhere else. Things like:
- Hooks or advising functions, where you can override any built-in or third-party function.
- Indirect buffers that allow you to view the same file through the lens of completely different contexts - imagine editing code comments as if you're writing Markdown.
- Unrivaled keyboard macros that can be saved as Lisp functions, providing flexibility for more advanced macro behavior.
- Integrated shells like Eshell where you can mix traditional shell commands with Lisp functions.
- TRAMP (Transparent Remote Access, Multiple Protocols) to access remote systems via a multitude of protocols, including ssh/scp, ftp, rsh/rcp, smb, even Docker. It eases the work of editing files on remote machines or containers by making them appear as though they are local files.
Emacs has some features that blow your mind and make you ask "But why?" and "Just how?". There's Calc that includes combinatorial functions, probability, statistics, and functions for number theory, conversion between hundreds of different units.
There's a built-in Calendar that knows how to calculate Lunar phases and Sunset and Sunrise based on your location. Can your IDE change its theme based on the time of day? Sure, VSCode has an extension for it. But can you hook into that extension and make it append a comment to every Git commit using info based on a function of that extension? In Emacs, you can do that without having to write another extension.
Don't say what other editors can do better than Emacs or just as good as Emacs. Because Emacs still makes it possible to do in an extremely hackable way that blows everything else out of the water in the hands of an experienced Emacs user.
From my perspective Emacs is one of those pieces of software or technology that will never die. Just like RSS.
But if you don't agree, and to quote the article:
> I get so tired of that trope. Don’t like Emacs? I’m fine with that. Sorry you’re missing out, but fine. What I’m not fine with is people who don’t like Emacs and probably have never used it seriously declaring it a spent force.
Thinking of Emacs simply as "an editor" is a misunderstanding that obscures its true nature and power. At its core, Emacs is an environment for seamlessly integrating a wide variety of tasks—text editing, shell command execution, software development, document formatting, and even games. The key ingredient enabling this amalgamation of features is Lisp, and most people when trying to talk about, learn, or understand Emacs often miss that point entirely.
Lisp is one of the oldest high-level PLs that is still very much in use today. Its longevity and vitality itself speaks volumes. While most computer languages are defined in terms of operations and structures specified in an arbitrarily chosen syntax, Lisp is fundamentally built on the simple structure of symbolic expressions. In other word, Lisp can be seen as 'the DNA' of programming languages.
From a philosophical viewpoint, Lisp embodies the concept of recursion. Recursion, philosophically, is a pattern that self-replicates, a principle we see in nature in things such as fractals, the Fibonacci sequence, and the structure of galaxies. In other words, Lisp encapsulates the concept of "everything is a subset of itself", reflecting the fractal nature of reality.
From a poetic point of view, Lisp is fluid, expressive and malleable. It allows metaprogramming, where programs can be designed to read, generate, analyze or transform other programs, and even modify themselves while running. This can lead to more concise, productive, and higher-level coding. In a sense, this reflects the poetic concepts of reflexivity, versatility and continuous evolution.
Lisp is famed for embodying the essence of simplicity. It's the epitome of elegance expressed through minimalism. Its design philosophy espouses the principle of composing complex operations from a smaller set of primitives. As T.S. Eliot once said, “When forced to work within a strict framework, the imagination is taxed to its utmost and will produce its richest ideas.”
The survival of Emacs is tied to the survival of Lisp, and Lisp is far from being obsolete. Its concepts are deep-seated in the world of programming and have shaped many modern languages. Just as Latin continues to live and breathe through its daughter languages and its impact across sciences, Lisp continues to pervade the technological universe due to its profound and timeless concepts.
Learn some Lisp, and maybe you'll realize what makes Emacs such a powerful, incredible, and extensible tool and why it is timeless.
It was dying when I started using it 15 years ago and it's been dying the whole time and still is. Apparently. Meanwhile I've had 15 years with Emacs and those who haven't have no idea what they're missing out on. Sad, but hey, you can't do everything in life.
The only Emacs users I've encountered in the wild were university professors who use Emacs pretty much out of the box. Never met another programmer who uses it. Plenty have seen me use it over the years and tried to pick it up, but don't think any have stuck with it like me.
For me Emacs is like a bicycle. It's the pinnacle of its technology class. Sure there are more convenient things like cars and VS Code, but these always come with tradeoffs and seem unsustainable in the long run. Emacs is a text editor for life.
> 15 years ago and it's been dying the whole time and still is
Exactly. Just like Latin has been 'dying' for nearly 2000 years, or since the fall of the Western Roman Empire in 476 AD. And while it's long been considered 'dead' language, it continues to influence modern languages and remains a subject of study and use today. Emacs in the same way just refuses to die. Lisp hackers keep improving it and building cool things.
Indeed, one could repurpose the "No steep learning curves; Just buttons to push and a lot of bling to make it look really cool." argument to conclude that the truth value of (dyingp emacs) is equivalent to the truth value of (dyingp computer-science).
I’ve worked as a web developer for over 10 years, eMacs is one of those things only strange people care about. Never really cared what text editor I use, seems really strange and time wasting.
My belief (from listening to students) is that vim using highly non-standard keys is seeing as a worth-while tradeoff for the extra editing power it provides. With emacs, it's not clear there is any advantage to emacs not using the standard ctrl+x,c,v,n,s,f, etc.