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?
Reminds me of Richard Stallman and how he used to do a character "St. igGNUcias of the Church of Emacs" who would answer questions like "Is using Vi a sin?" with "Yes, but one that is its own penance!"
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.
Yeah, before Emacs, it never occurred to me to even think of trying to control my browser from my editor.
I never thought that I can type just about any text, not in the input box of some app, but in my editor - with Emacs, if I need to type anything longer that three words - in Slack app, Zoom chat, browser window, etc., I'll do it in my editor, why have I never thought about this before?
Emacs has no business of taking screenshots, yet I use it to do just that - I'd insert a screenshot while taking notes, OCRing the text out of image when desired.
Before Emacs, I never thought of playing and controlling videos from my editor or driving my WM from it - I simply never thought how advantageous could that even be.
I can't really use anything else without feeling constrained specifically because [mostly] nothing else allows me to type some Lisp in just about any buffer, evaluate it in place and immediately affect not only my editor but any computational aspect on a local or remote machine.
In essence, Emacs is a mindset. Non-Emacs folk often don't see the "actual use cases" because their minds operate on a different plane. And for some, once they crack open that door of possibilities, there's really no turning back.
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 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.
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.
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.
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.
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
Emacs in its half-a-century existence afaik never had "batteries included" narrative. Whatever comes bundled in Emacs, either practical or not so much (e.g. tetris) - are recipes and guides for extending it.
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.
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.
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.
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.
I think the same. Even if today I'm a die hard HJKL user, Emacs' doctor and the whole nerdiness world from M-x doctor to M-x fortune among M-x dunnet (and the rest of the games) opened a total new world instead of the damn boring Microsoft world with their own obscure terms making things nearly undiscoverable and very difficult to understand because there was no complete documentation for the end user.
Later, in mid-2000's, the 3 DVD based Debian Sarge came with everything. Documentation, serious software, programming tools, mega nerd/geek games, the Anarchist FAQ, crazy fortune files, nerd lore and whatnot. You could snoop your BTTV and later DVB signals on the fly (even decode some channels my normal TV wasn't able to do), break tons of limits on cable TV sets (even override them)... it was magical.
I too am an apostate, however the post has gone a long way to encouraging me back into the fold, couldn't find my old .emacs when I had a quick look yesterday, dread starting again but maybe that's a meditation in itself.
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…
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.
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.
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
2) I have eshell bound to a keybind, but I've never use it. I prefer shell-mode and shell-command. They make it easy to use cli utilities. TUI is something that I find myself no longer needing. And I've become so accustomed with the cli that the only two I'm using in a terminal is `less` and `top`.
3) I think the best way is to find some vanilla base config that will smooth out the rough parts, then, once you understand the internal concepts, tweak them to your liking. It's certainly a long term plan, but the pro is not having to wait on "features" from another company or group.
> I have eshell bound to a keybind, but I've never use it
For years, I had a similar feeling about it. And then I learned that in eshell you can pipe in and out of buffers. So you can for example grep the content of one buffer and pipe results into another. Or pipe the output of a command to a buffer, and you even can chain them pipes. That often comes extremely handy.
Readit News
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?
https://www.youtube.com/watch?v=urcL86UpqZc
Emacs, too, is bigger on the inside.
I never thought that I can type just about any text, not in the input box of some app, but in my editor - with Emacs, if I need to type anything longer that three words - in Slack app, Zoom chat, browser window, etc., I'll do it in my editor, why have I never thought about this before?
Emacs has no business of taking screenshots, yet I use it to do just that - I'd insert a screenshot while taking notes, OCRing the text out of image when desired.
Before Emacs, I never thought of playing and controlling videos from my editor or driving my WM from it - I simply never thought how advantageous could that even be.
I can't really use anything else without feeling constrained specifically because [mostly] nothing else allows me to type some Lisp in just about any buffer, evaluate it in place and immediately affect not only my editor but any computational aspect on a local or remote machine.
In essence, Emacs is a mindset. Non-Emacs folk often don't see the "actual use cases" because their minds operate on a different plane. And for some, once they crack open that door of possibilities, there's really no turning back.
Writing Visual Studio, for example. Debugging Visual Studio. Extending Visual Studio in more than the ways it has already provided.
It means not being constrained to do only those things someone else had seen fit to permit you to do. It means freedom.
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.
They could at least change the default theme to one of the already-bundled modus-themes or something.
Out of the box, project and context aware auto complete is an essential feature in a modern IDE.
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.
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.
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.
- 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.
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.
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.
- 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.
There are ways to search and grep files on Windows.
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.
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.
...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.
...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.
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.
Later, in mid-2000's, the 3 DVD based Debian Sarge came with everything. Documentation, serious software, programming tools, mega nerd/geek games, the Anarchist FAQ, crazy fortune files, nerd lore and whatnot. You could snoop your BTTV and later DVB signals on the fly (even decode some channels my normal TV wasn't able to do), break tons of limits on cable TV sets (even override them)... it was magical.
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…
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.
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.
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.
3) I think the best way is to find some vanilla base config that will smooth out the rough parts, then, once you understand the internal concepts, tweak them to your liking. It's certainly a long term plan, but the pro is not having to wait on "features" from another company or group.
For years, I had a similar feeling about it. And then I learned that in eshell you can pipe in and out of buffers. So you can for example grep the content of one buffer and pipe results into another. Or pipe the output of a command to a buffer, and you even can chain them pipes. That often comes extremely handy.
Or vterm if you don't want to be proficient with eshell.