This essay is amazing and delightful, but it is rather densely allusive, like classical Chinese literature; ultimately it is more allusion than plain language. I suspect that most people will find it somewhat impenetrable. But if you want to see Emacs explained by references to Dune, Harry Potter, Gormenghast, Star Wars, A Rape in Cyberspace, Neuromancer, The Matrix, Crowleyian magick, and so on, this essay is for you.
Ultimately such storytelling seems to be the best means that we as humans have to convey our subjective experiences, which purely objective descriptions are not very good at. (This is one of the weak points of the engineering mindset that I was criticizing in https://news.ycombinator.com/item?id=45650941.) So I sympathize with the project. But I wonder if it may end up preaching to the choir a bit: if you remember the intoxication of reading Barlow's Declaration of Independence, probably you already have a settled relationship with Emacs, whether intimate or traumatic, or both?
I was shocked by the reference to Navidson's house from the House of Leaves. The ending to your first paragraph is also interesting in that HoL starts with "This is not for you."
House of Leaves is something I've been wanting to read since I first saw it, but I've never had the chance. Unlike most books, I feel that I'd be missing out on a lot if I didn't read it in physical form.
To me the charming thing about Emacs is how introspective a program it is. This goes beyond all the documentation being built-in, and being able to redefine things on the fly. For instance, it's easy to define a keybinding that does "Take me to the source code of the command that's bound to the next keybinding I type". When you use that and land at a destination, it will probably be Elisp code, but in some cases will even be C code - it works either way.
That and how smooth the customization curve is, from tweaking settings, to recording keyboard macros, to writing small helper functions, to creating whole packages. Compare that to something like Eclipse or IntelliJ, where there's a huge gap between changing settings and creating plugins. It's a sweet spot between semi-configurable text editors and full-blown "living ball of mud" systems like Lisp and Smalltalk.
I struggled with a complex manuscript for years and tried all sorts of tools from Word to Scrivener in the process with no luck.
Emacs w/org mode was the only program that helped me make sense of the mess and finish the darn thing. I have never seen a program so elegant and yet so powerful, and I am forever grateful it exists if only as a counterweight to the modern tech paradigm.
I didn't want the post to end I didn't want to return to an existence where people don't share these transgressive impulses with me.
This is a robust and comprehensive antidote to nihilism and anyone who has ever missed the internet of the nineties or early 00s as I have would be doing themselves an enormous favour by reading it, and then rereading it as I intend to.
It lost me for a moment at Implicity and I was worried the spell had be broken but the profound blows didn't stop.
While I still use emacs, I find that that despite the "batteries included" narrative about emacs, the things which are not included are causes of major frustration.
Such essential functionality like grep-find and LSP servers which is required for out of the box auto complete are not bundled with emacs. Most modern IDEs/editors have these functionality baked in.
If you install emacs for windows you find that grep-find doesn't work, because it depends on support from environment. A full text search should be built into the editor.
I've never used grep-find or LSP, despite using Emacs for 32 years. Maybe I should; is grep-find better than M-x grep?
Apparently I've sometimes improvised an equivalent: "Run grep via find, with user-specified args COMMAND-ARGS. ...
This command uses a special history list for its arguments, so you can easily repeat a find command."
My out-of-the-box autocomplete is M-/, which works in environments where LSP doesn't, like writing English. It works sort of poorly in all of them, but I write production code slowly enough that my typing speed isn't close to being a bottleneck. It's more of a bottleneck when writing English, but even there, generally any of my good writing was good rewriting.
Where I've found LSP-like functionality really useful in the past in IDEA and later Eclipse was not autocomplete, which is mostly an annoyance, but in automated refactoring (extract variable, extract method, inline method) and in rapidly iterating through the implementors of a method whose semantics I'm changing.
That seems reasonable, yeah. ripgrep, etc., are definitely faster.
Somehow I never twigged that you wrote Ardour and JACK. Thanks for JACK! (My audio editing needs are very modest and so I haven't actually tried Ardour.)
I don't think lsp servers should be bundled, they're often huge, and e.g. for haskell you need the one that matches your ghc version, so you'd need ..all of them? and they need to be kept up-to-date etc. There is an emacs LSP server package manager at https://github.com/deirn/mason.el though – maybe something like that could be included, and Emacs could suggest how to install an appropriate LSP server (and enable eglot). I know many of the old hackers bristle at this, but I think it should be possible to do some kind of helpful but non-intrusive hinting for new users (one can always `setq clippy nil`)
They could at least change the default theme to one of the already-bundled modus-themes or something.
Once we get a modern IDE like PyCharm or Intellij Idea, the auto complete is essentially built in, without needing to deal with installing LSP servers, clients, and their dependencies.
Out of the box, project and context aware auto complete is an essential feature in a modern IDE.
Last I checked, an IDE like Android Studio (based on IDEA) needs to download a hogshead of java before it can even begin to build anything. And if you switch compiler versions, it needs to download even more. Sure it makes installing java as easy as clicking a few buttons, and it'd be great if Emacs made it as easy, but still: it doesn't bundle every version. No one would have the drive space for that.
And now consider that emacs has support for not just java/kotlin, but pretty much every programming language in existence..
Emacs is not a “modern IDE” and expecting it to be one is a recipe for not only confusion and irritation but also for watering down the goodness that it really is.
I don't think I've ever heard emacs described as "batteries included" -- maybe more like "batteries available." If anything it has the opposite reputation, that doing anything requires extensive and continual config adjustments, which isn't accurate either.
There are plenty of emacs "starter kits" that do aim to provide more of a batteries included experience. My favorite is doom, it's worth checking out and does setup all the features you mention.
Pointing new users at those more advanced default configs as an option would be pretty helpful, I think.
Tbh even though I got my start with Emacs Live I really do think at this point the simplest way to get started is to start vanilla and stay as vanilla as possible as you slowly build up your config based on simple and straightforward examples. The main problem is the utter lack of such examples in the community. I had to figure it out for myself for the most part. KISS!
Emacs isn’t battery-included. It’s a platform for textual interfaces with a focus on text editing. It may not includes some tools, but if the tools works with text (at least on the standard in/out) hooking it in emacs can be done really quickly. More so if it’s something that:
- have result that can be formatted in a tabular fashion
- do stuff with files then present some diagnostics (especially if errors and warnings are related to the files)
- Have an REPL interface
It’s not preconfigured like VS Code, but it’s much more versatile. Cursor having to fork VSCode is one such example. In Emacs, anything is just another package.
I think the mistake is looking at Emacs as an editor. It's an Emacs Lisp VM, and the editor that comes bundled with it is good, but not great. Fortunately there are many ways to improve it, and make it go beyond what other editors can.
For most modern programming languages, LSP servers are trivial to install. You can usually get them through your language or distro's package manager in one command line invocation. Considering that there are sometimes multiple servers with their own pros and cons for a language, this can be kinda nice.
The only one I've ran into that is different is Java, but considering how underdeveloped Java LSP servers are, you probably don't want to be using emacs for Java development.
parent is talking about the external dependencies, grep.exe and java and jdtls etc., and in particular how they need to be installed separately from Emacs
Do other editors and IDEs bundle-in these external language servers? I don't think so, unless they are specifically tied to the language like Eclipse or PyCharm
XEmacs only came about because Lucid needed a front end to their IDE, Energize, which was extremely comprehensive and could even do "edit and continue" style development of C++ on Unix but, as jwz has it, the Unix community preferred its stone-knives-and-bearskins approach with command line tools.
Yeah, Solaris and NeXTSTEP were the only UNIXes that had an IDE tooling story from the vendors.
Thanks to its origin, XEmacs also had for several years many graphical capabilities, that if I am not mistaken only landed on main Emacs during the late 2000's, by then I was back into IDE land.
The criticism makes sense when you consider that yeah, while posix tools are okay, needing them everywhere means you have something wrong in your programming ecosystem, and Elisp has many things wrong.
Emacs can easily work with non-posix tools. Many people use ag, ripgrep, or ack in lieu of grep. You change the command string Emacs uses for finding and grepping to your tool of choice.
WSL2. While it's a fair criticism, the underlying issue here is that there aren't enough Windows users who program and upstream things for individual users to get support. Lean on the Linux ecosystem and things are fine.
The reason there aren't programmers targeting the large market is a tangent into why I'm building PrizeForge, but the answer now doesn't change.
Umm. Is this some sort of troll article? It sucks you in with nerd nostalgia and slowly becomes more and more esoteric and insane.
Here’s the final two lines:
> We should know better than to prematurely optimize for order when all of all time arrowpoints in and down to the absolute return 0. Words of wisdom, let it be: your world is a fine stream of consciousness, lacking only a decent editor.
If that feels like your jam, go for it, but personally I feel in need of an exorcist after letting my computer load this…
This hit home for me. I spent about 6 months working exclusively with emacs to get past the "this is weird/hard because it is unfamiliar to me" stage. At the end of the experiment, I went back to using vim and IDEs.
My take personal takeaways from the experience:
1) capslock/ctrl switching is helpful in so many other areas - so I kept that
2) emacs is something you want to "live in" (e.g. learning to rely on eshell) if you want to really become proficient with it
3) emacs is something you have to be willing to tweak/adjust via elisp to suite your personal preferences if you want to really really really be proficient with it
Man, I totally get this. I've been an Emacs user for 30 years and counting; back in the mid-90s when I started on Linux, I learned that the truly wizardly hackers usually used one of vim or Emacs and because I disliked modal editing, I chose Emacs—only to find myself tumbling down a deep, deep rabbithole that opened into an unfathomable warren network it would take me decades to begin to make any sense of.
When I open Emacs, it's like I'm five years old again, seated at my VIC-20, confronted with the infinite possibilities of the machine, challenged to explore them. Except the possibilities are so much greater because computers can do so much more and Emacs—as the programmable way to program—puts them virtually all at my fingertips. It's all a bit overwhelming, and this essay does a good job of capturing that overwhelm and the shift in perspective needed to cope.
That said, it's likely to send most people screaming back whence they came, clinging ever more firmly to their Visual Studio Codes and IntelliJs, if they be programmers at all and if not, it may turn them off programming altogether. Because that perspective shift looks like utter madness from the outside. I don't think we as a species are ready for computers yet. The possibilities, the implications.
Since employment is apparently the highest achievement a person can aspire to, this post and emacs users in general, must be of such lesser value I guess? /s
Never in my 20 years of programming, data engineering, engineering management of games, search engines, dating apps and machine learning systems I had a problem of people not wanting to hire me because I prefered Emacs (and linux).
This essay is amazing and delightful, but it is rather densely allusive, like classical Chinese literature; ultimately it is more allusion than plain language. I suspect that most people will find it somewhat impenetrable. But if you want to see Emacs explained by references to Dune, Harry Potter, Gormenghast, Star Wars, A Rape in Cyberspace, Neuromancer, The Matrix, Crowleyian magick, and so on, this essay is for you.
Ultimately such storytelling seems to be the best means that we as humans have to convey our subjective experiences, which purely objective descriptions are not very good at. (This is one of the weak points of the engineering mindset that I was criticizing in https://news.ycombinator.com/item?id=45650941.) So I sympathize with the project. But I wonder if it may end up preaching to the choir a bit: if you remember the intoxication of reading Barlow's Declaration of Independence, probably you already have a settled relationship with Emacs, whether intimate or traumatic, or both?
I was shocked by the reference to Navidson's house from the House of Leaves. The ending to your first paragraph is also interesting in that HoL starts with "This is not for you."
House of Leaves is something I've been wanting to read since I first saw it, but I've never had the chance. Unlike most books, I feel that I'd be missing out on a lot if I didn't read it in physical form.
Emacs, too, is bigger on the inside.
To me the charming thing about Emacs is how introspective a program it is. This goes beyond all the documentation being built-in, and being able to redefine things on the fly. For instance, it's easy to define a keybinding that does "Take me to the source code of the command that's bound to the next keybinding I type". When you use that and land at a destination, it will probably be Elisp code, but in some cases will even be C code - it works either way.
That and how smooth the customization curve is, from tweaking settings, to recording keyboard macros, to writing small helper functions, to creating whole packages. Compare that to something like Eclipse or IntelliJ, where there's a huge gap between changing settings and creating plugins. It's a sweet spot between semi-configurable text editors and full-blown "living ball of mud" systems like Lisp and Smalltalk.
I struggled with a complex manuscript for years and tried all sorts of tools from Word to Scrivener in the process with no luck.
Emacs w/org mode was the only program that helped me make sense of the mess and finish the darn thing. I have never seen a program so elegant and yet so powerful, and I am forever grateful it exists if only as a counterweight to the modern tech paradigm.
I didn't want the post to end I didn't want to return to an existence where people don't share these transgressive impulses with me.
This is a robust and comprehensive antidote to nihilism and anyone who has ever missed the internet of the nineties or early 00s as I have would be doing themselves an enormous favour by reading it, and then rereading it as I intend to.
It lost me for a moment at Implicity and I was worried the spell had be broken but the profound blows didn't stop.
While I still use emacs, I find that that despite the "batteries included" narrative about emacs, the things which are not included are causes of major frustration.
Such essential functionality like grep-find and LSP servers which is required for out of the box auto complete are not bundled with emacs. Most modern IDEs/editors have these functionality baked in.
If you install emacs for windows you find that grep-find doesn't work, because it depends on support from environment. A full text search should be built into the editor.
I've never used grep-find or LSP, despite using Emacs for 32 years. Maybe I should; is grep-find better than M-x grep?
Apparently I've sometimes improvised an equivalent: "Run grep via find, with user-specified args COMMAND-ARGS. ... This command uses a special history list for its arguments, so you can easily repeat a find command."
My out-of-the-box autocomplete is M-/, which works in environments where LSP doesn't, like writing English. It works sort of poorly in all of them, but I write production code slowly enough that my typing speed isn't close to being a bottleneck. It's more of a bottleneck when writing English, but even there, generally any of my good writing was good rewriting.
Where I've found LSP-like functionality really useful in the past in IDEA and later Eclipse was not autocomplete, which is mostly an annoyance, but in automated refactoring (extract variable, extract method, inline method) and in rapidly iterating through the implementors of a method whose semantics I'm changing.
To be fair, running grep from Emacs is a mistake - you should be using ag, or some other parallelized version of grep :)
Ardour has around 800k lines of code, and ag (not even the fastest of the new greps) can search it all more or less faster than I can type.
The idea of some system that analyzes/caches/indexes the code just isn't necessary anymore.
That seems reasonable, yeah. ripgrep, etc., are definitely faster.
Somehow I never twigged that you wrote Ardour and JACK. Thanks for JACK! (My audio editing needs are very modest and so I haven't actually tried Ardour.)
I don't think lsp servers should be bundled, they're often huge, and e.g. for haskell you need the one that matches your ghc version, so you'd need ..all of them? and they need to be kept up-to-date etc. There is an emacs LSP server package manager at https://github.com/deirn/mason.el though – maybe something like that could be included, and Emacs could suggest how to install an appropriate LSP server (and enable eglot). I know many of the old hackers bristle at this, but I think it should be possible to do some kind of helpful but non-intrusive hinting for new users (one can always `setq clippy nil`)
They could at least change the default theme to one of the already-bundled modus-themes or something.
Once we get a modern IDE like PyCharm or Intellij Idea, the auto complete is essentially built in, without needing to deal with installing LSP servers, clients, and their dependencies.
Out of the box, project and context aware auto complete is an essential feature in a modern IDE.
Last I checked, an IDE like Android Studio (based on IDEA) needs to download a hogshead of java before it can even begin to build anything. And if you switch compiler versions, it needs to download even more. Sure it makes installing java as easy as clicking a few buttons, and it'd be great if Emacs made it as easy, but still: it doesn't bundle every version. No one would have the drive space for that. And now consider that emacs has support for not just java/kotlin, but pretty much every programming language in existence..
Emacs is not a “modern IDE” and expecting it to be one is a recipe for not only confusion and irritation but also for watering down the goodness that it really is.
Except pycharm won't work with my erlang lsp.
I don't think I've ever heard emacs described as "batteries included" -- maybe more like "batteries available." If anything it has the opposite reputation, that doing anything requires extensive and continual config adjustments, which isn't accurate either.
There are plenty of emacs "starter kits" that do aim to provide more of a batteries included experience. My favorite is doom, it's worth checking out and does setup all the features you mention.
Pointing new users at those more advanced default configs as an option would be pretty helpful, I think.
But many features, even obscure ones are packaged by default in modern emacs, including I think a pdf viewer.
Tbh even though I got my start with Emacs Live I really do think at this point the simplest way to get started is to start vanilla and stay as vanilla as possible as you slowly build up your config based on simple and straightforward examples. The main problem is the utter lack of such examples in the community. I had to figure it out for myself for the most part. KISS!
Emacs isn’t battery-included. It’s a platform for textual interfaces with a focus on text editing. It may not includes some tools, but if the tools works with text (at least on the standard in/out) hooking it in emacs can be done really quickly. More so if it’s something that:
- have result that can be formatted in a tabular fashion
- do stuff with files then present some diagnostics (especially if errors and warnings are related to the files)
- Have an REPL interface
It’s not preconfigured like VS Code, but it’s much more versatile. Cursor having to fork VSCode is one such example. In Emacs, anything is just another package.
I think the mistake is looking at Emacs as an editor. It's an Emacs Lisp VM, and the editor that comes bundled with it is good, but not great. Fortunately there are many ways to improve it, and make it go beyond what other editors can.
For most modern programming languages, LSP servers are trivial to install. You can usually get them through your language or distro's package manager in one command line invocation. Considering that there are sometimes multiple servers with their own pros and cons for a language, this can be kinda nice.
The only one I've ran into that is different is Java, but considering how underdeveloped Java LSP servers are, you probably don't want to be using emacs for Java development.
What? Emacs has eglot built in. It has had native grep and find stuff for decades.
https://www.gnu.org/software/emacs/manual/html_node/emacs/Gr...
You can change the exec-path to point to your cross compiled grep tool --- or you can change the command string to your tool of choice.
I think for grep in emacs, the only thing require is the interface:
- result on standard output - path and line numbers on each line
A lot of emacs reliance on other tools follow the same pattern. While the default is posix, it has enough options to twist it to fit whatever OS.
parent is talking about the external dependencies, grep.exe and java and jdtls etc., and in particular how they need to be installed separately from Emacs
Do other editors and IDEs bundle-in these external language servers? I don't think so, unless they are specifically tied to the language like Eclipse or PyCharm
Define modern.
IDEs with such capabilities were already available in the 1990's.
I became an XEmacs user in the 1990's, because there was hardly anything better in UNIX systems.
Remember, Emacs still lacked many niceties only available on XEmacs, and vim was yet to be invented.
This is how old such IDE features have been available.
XEmacs only came about because Lucid needed a front end to their IDE, Energize, which was extremely comprehensive and could even do "edit and continue" style development of C++ on Unix but, as jwz has it, the Unix community preferred its stone-knives-and-bearskins approach with command line tools.
Yeah, Solaris and NeXTSTEP were the only UNIXes that had an IDE tooling story from the vendors.
Thanks to its origin, XEmacs also had for several years many graphical capabilities, that if I am not mistaken only landed on main Emacs during the late 2000's, by then I was back into IDE land.
Why not instead blame Windows for not having the standard tools “grep” and “find”?
UNIX standard tools, and not every operating system is supposed to be a UNIX clone.
There are ways to search and grep files on Windows.
Feel free to add the code to use something else by default on Windows: <https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/lisp/p...>
The criticism makes sense when you consider that yeah, while posix tools are okay, needing them everywhere means you have something wrong in your programming ecosystem, and Elisp has many things wrong.
Emacs can easily work with non-posix tools. Many people use ag, ripgrep, or ack in lieu of grep. You change the command string Emacs uses for finding and grepping to your tool of choice.
the total lack of “getting it” on display here is simply flabbergasting.
WSL2. While it's a fair criticism, the underlying issue here is that there aren't enough Windows users who program and upstream things for individual users to get support. Lean on the Linux ecosystem and things are fine.
The reason there aren't programmers targeting the large market is a tangent into why I'm building PrizeForge, but the answer now doesn't change.
>If you install emacs for windows...
...you are a second class citizen in the emacs republic.
I mean, I don't endorse this position, but it's the way things are.
>If you install emacs for mac...
...you are a third class citizen in the emacs republic.
In spite of the fact that you can't spell emacs without mac.
Also:
>If you install emacs for linux...
...you get flamed for not calling it gnu/linux.
I use emacs on a Mac and it is dead easy, so I'm not sure what you mean by this. I had to do nothing at all to make it work. It just worked.
Emacs for Mac is fine though?: https://github.com/jimeh/emacs-builds
That build has native compilation, and if you go for a Doom install you may need to build ripgrep yourself, but... that's also not difficult.
they mean you live within the walled garden, that you are playing make-believe.
That's not true, either, but I understand it's important for a certain sort of FOSS person to believe it anyway.
Umm. Is this some sort of troll article? It sucks you in with nerd nostalgia and slowly becomes more and more esoteric and insane.
Here’s the final two lines:
> We should know better than to prematurely optimize for order when all of all time arrowpoints in and down to the absolute return 0. Words of wisdom, let it be: your world is a fine stream of consciousness, lacking only a decent editor.
If that feels like your jam, go for it, but personally I feel in need of an exorcist after letting my computer load this…
Author is a lapsed Catholic, it checks out (speaking as a former lapsed Catholic who knows lapsed Catholics)
My take personal takeaways from the experience:
1) capslock/ctrl switching is helpful in so many other areas - so I kept that
2) emacs is something you want to "live in" (e.g. learning to rely on eshell) if you want to really become proficient with it
3) emacs is something you have to be willing to tweak/adjust via elisp to suite your personal preferences if you want to really really really be proficient with it
I didn't hate emacs but it also wasn't for me.
> e.g. learning to rely on eshell
Or vterm if you don't want to be proficient with eshell.
I've been using emacs for over 20 years and had no idea about `M-x tetris`. Worth reading just for that!
Man, I totally get this. I've been an Emacs user for 30 years and counting; back in the mid-90s when I started on Linux, I learned that the truly wizardly hackers usually used one of vim or Emacs and because I disliked modal editing, I chose Emacs—only to find myself tumbling down a deep, deep rabbithole that opened into an unfathomable warren network it would take me decades to begin to make any sense of.
When I open Emacs, it's like I'm five years old again, seated at my VIC-20, confronted with the infinite possibilities of the machine, challenged to explore them. Except the possibilities are so much greater because computers can do so much more and Emacs—as the programmable way to program—puts them virtually all at my fingertips. It's all a bit overwhelming, and this essay does a good job of capturing that overwhelm and the shift in perspective needed to cope.
That said, it's likely to send most people screaming back whence they came, clinging ever more firmly to their Visual Studio Codes and IntelliJs, if they be programmers at all and if not, it may turn them off programming altogether. Because that perspective shift looks like utter madness from the outside. I don't think we as a species are ready for computers yet. The possibilities, the implications.
[dead]
That he burned 11,000 words on his text editor tells you why emacs users are unemployable.
I'm an employed emacs user and more than half of my team also uses emacs
Since employment is apparently the highest achievement a person can aspire to, this post and emacs users in general, must be of such lesser value I guess? /s
employment is apparently the highest achievement a person can aspire to
Your words, not mine. But gene propagation is up there, and steady wages is a sufficient if not necessary condition for that to happen.
Never in my 20 years of programming, data engineering, engineering management of games, search engines, dating apps and machine learning systems I had a problem of people not wanting to hire me because I prefered Emacs (and linux).
In fact, in was the opposite.
So what are you even talking about?
==WARNING== Palantir's `blackbriar' uber-flag alert cycling 24/7, must include: hacker news, linux, emacs, mathe... and.. likely off-ed before the morrow..best sto