Is Emacs dying?
irreal.org
irreal.org
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.
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.
Yes, we call those modes.
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.
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.
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
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.
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.
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.
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.
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.
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.
That being said: try to press "." while you are looking at a project in Github.
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
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).
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
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.
My thinking is that if you need vim you actually need an ide or lightweight ide.
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'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.
> 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.
That says it all
We need more of it.
Yet the simple solution of not letting in people who can't code a working sorting algorithm is seen as some type of crime against humanity.
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.
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)
Who knew!
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.
One of my managers used to say that the only reason people write software is because there isn't already an emacs or Excel macro to do what they need.
It’s never a good thing that Microsoft has majority market share.
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.
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.
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.
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
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.
>User studies don't apply here, it's too complex
User studies always apply. And doing basic everyday source control operations should not be complex.
Fair point about massive hunk set causing lag, it's plausible.
Additionally it has not one but two tab modes built-in (tab-line-mode, tab-bar-mode)
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.
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 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.
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".
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.
The language server was a nice idea but so long and thanks for all the fish.
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.
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 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.."
One thing that I wondered is how to make the manual more lispy/repl oriented.
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.
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.
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.
> Great trolling.
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.
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.
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...
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.
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.
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.
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!
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.
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.
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.
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.
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.
my eyebrows launched off of my face
Then there is the individual preference between vim and emacs
other tools like Eclipse and bash have emacs keybindings to repay the muscle memory investment
- 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.
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.
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.
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.
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.
They've all worked just fine.