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.
Yes, it's definitely something you want to experience in the physical form! It's hard to describe what reading it feels like towards the latter parts of the book- you feel like you're lost in the book like how the Navidson gets lost in the house.
I keep track of my Emacs with a Tractive GPS collar, and I have an app on my phone that shows the trails and a heat map of everywhere he's been. And I debug him with Frontline, but that doesn't prevent him from coming in with slugs in his fur. (Emacs is my cat's name.)
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 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.
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.
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'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 customized grep-find on my setup. I have a shell script so that it does the following (in typescript-mode)
first search ts, tsx, js, jsx files in the current project. Exclude .git, node_modules...
then search node_modules with the ts.. extensions, still exclude .git
finally search the whole tree for .py files still exclude .git, /dist...
This is coupled with consult-find-grep. I basically want to find a string in the most relevant file type. I never want a result from node_modules first in the results. It took some work, but the results are quite nice!
Oh, yeah, I wrote some Emacs Lisp that did that kind of project-specific thing for a Perl project I was working on for a couple of years in 02003 and 02004. One function key would search the whole project for occurrences of the identifier under the cursor, and another one would search for definitions.
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 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.
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
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.
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.
Given that was in 2008, I would update his remark from Netbeans, to any of JetBrains products, Eclipse or whatever.
In any case, you can get those features using Windows Resource Toolkit on the old days, a mix of findstr and other similar improvements on Windows NT linage, nowadays Powershell will be enough.
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.
Color emoji was deliberately disabled on macOS (2016): policy first, parity later.
Emacs 25 turned off multicolor fonts on the Cocoa port even though they worked, with a NEWS note saying they’d be re-enabled "once it is also implemented in Emacs on free operating systems." This was widely read as a political parity requirement that penalized macOS users for years.
"Prefer GNU/GNU-Linux" development time: an explicit guideline.
GNU’s own standards advise spending time on features "useful on GNU and GNU/Linux, rather than on supporting other incompatible systems." That guideline has often been cited in Emacs discussions to argue against platform-specific work that would land only on macOS.
macOS-only features face extra process friction, or must be generalized.
The "send-to" (macOS Sharing) patch was finally merged in 2025 -- but only after a lengthy debate and a rework into a cross-platform framework to satisfy GNU policy concerns about adding features that target a non-free OS first. (The end result is good! -- but the path illustrates the extra hurdles for macOS-first work.)
Long-running reliance on mac-specific forks to get a polished UX.
For years, many mac users have depended on Mitsuharu Yamamoto's Emacs Mac port (emacs-mac) or distributions like Aquamacs to get native scrolling, gestures, font/rendering tweaks, and other integrations that either lagged upstream or weren’t accepted. The continued popularity and active maintenance of these forks reflects a gap in first-party mac attention.
Recent high-profile macOS performance pathology highlighted as "non-primary platform" pain.
In 2025, a widely-read analysis ("Emacs: The macOS Bug") traced severe jank/memory growth to how Emacs drives Cocoa’s runloop (e.g., NSApp run usage inside the select/IO path), arguing that historical architecture -- plus macOS not being a primary target -- left deep issues unaddressed for years. Follow-on bug threads on emacs-devel discuss memory fragmentation and event handling. This is more engineering history than politics, but it shows practical consequences of platform de-prioritization.
FSF position on non-free systems frames the culture.
FSF materials repeatedly emphasize using and prioritizing free systems. Even where they explicitly say they didn’t drop support for non-free OSes, the values signal still affects triage, reviews, and what maintainers feel comfortable merging first. This shapes outcomes like color emoji support and the review friction in the "send-to" patch.
2008–2010, the long, bumpy road to a native Mac port:
During Emacs 23’s cycle the old Carbon port was "completely broken ... for almost a year," and was ultimately removed when the new Cocoa/Nextstep port was merged. For years many Mac users relied on forks (Aquamacs, Mitsuharu's "Emacs Mac Port") for a smoother experience, reinforcing the "not a first-class target" vibe.
RMS isn't only against Emacs on Macs and Windows. He also has some strong opinions about UniPress Software, who sold a version of Gosling's Emacs for Gosling's own NeWS window system, Apple Lisa, Mac, MS-DOS, Amiga, Xenix, SGI IRIX, Intergraph, xePIX, Northern Telecom, Cadmus, DEC Rainbow, VMS, VAX BSD, DECWRL Titan, TI Professional, Masscomp, Apollo, HP, Stride, AT&T 3B, System V, Gould, NBI U! ("Nifty Box"), Pyramid, Perkin-Elmer, Cray UniCos, and many other proprietary Unix systems.
>I worked at UniPress on the Emacs display driver for the NeWS window system (the PostScript based window system that James Gosling also wrote), with Mike "Emacs Hacker Boss" Gallaher, who was charge of Emacs development at UniPress. One day during the 80's Mike and I were wandering around an East coast science fiction convention, and ran into RMS, who's a regular fixture at such events.
>Mike said: "Hello, Richard. I heard a rumor that your house burned down. That's terrible! Is it true?"
>RMS replied right back: "Yes, it did. But where you work, you probably heard about it in advance."
>Everybody laughed. It was a joke! Nobody's feelings were hurt. He's a funny guy, quick on his feet!
I've got another one for macOS. It's not as significant as what you listed, but it was extremely annoying for me.
When using homebrew, the default package for emacs is version 30. However, that version on macOS was compiled with an outdated tree-sitter version (v14). If one tries to install a tree-sitter parser for a particular language it will not work with emacs 29 or 30 on macOS (or at least not that I could figure out). I tried the D12Frosted version and some of the alternatives for macOS (I forget the names).
The current tree-sitter project is on v15+, so in order for it to work, one has to go through the commit histories for each language and find when the tree sitter's parser version was last compatible with v14. To my knowledge, this was not clearly listed in all the git commits in a nice clean manner.
One alleged workaround was to install everything via RedHat OS and move the installed parsers over to macOS since their version of emacs and the tree-sitter parsers are still compatible. However, I was not interested in doing this.
Interestingly enough, Neovim does not have this issue on macOS to my knowledge, but I could be wrong.
Now, this is not entirely an emacs issue, but it does introduce an interesting issue. If emacs has to be compiled with a particular tree-sitter version, then it makes things quite difficult to maintain. The maintainers apparently are discussing various options on how to handle this going forward, but there isn't a clear way to work around this.
Now, I do believe if one builds emacs from source, he or she can work around this issue to some degree, but I was also not interesting in doing this because one loses out on some of the nice features that the macOS focused emacs versions come with. I also did not want to install all the dependencies required to build from source since those dependencies are not something I have any other use for other than building emacs.
So, I just gave up on the tree-sitter. Though, I think emacs 31 has this fixed until it happens again, but I also encountered a lot of other bugs when trying other use it since it's a prerelease version anyway.
This was all months ago, so maybe things have changed. I haven't kept up. I can live without tree-sitter for the time being.
Wow that's a wall of text proving pretty much nothing, other than that RMS is an out of touch goofball.
As I and others have noted, actually using emacs on a Macintosh is dead easy. MacOS ships with an older terminal version, so you don't even have to download anything if you're fine with that distro. OTOH, multiple native build distributions exist and are a click away.
I spend a good chunk of my day in a native build between text, scripting, and Orgmode, and, again, it's just not a problem. It's far easier, in fact, to use emacs on a Mac than on Windows precisely because MacOS is a unixy environment.
It only proves nothing if you didn't bother reading it (which you words "wall of text" imply) and didn't check any of the links proving what I said. Instead of dismissing everything by handwaving, please tell me which specific points I made that you disagree with, and what is your evidence?
How long have you been using Emacs, yourself? If you just got started a few years ago, then that excuses your ignorance of history (but not your unwillingness to learn), but there is a LOT of well documented history about Emacs on the Mac, and all those links you didn't bother following prove it.
You can't win an argument by being ignorant of history, claiming tl;dr, and refusing to look at the evidence. That's just conceding my points by default. Can you do any better than that?
It feels like this changed roughly in the last five years. That's about how long I've been using Emacs on Mac.
I'd mostly been using Sublime / Atom / Eclipse / Vim before that (and a long list of other IDEs and editors going back to Turbo Pascal 3.0 on IBM XTs). So perhaps I've not felt the same pain.
I'm glad I can use Emacs at work (on Macs) and at home (on Linux). The funny thing is it's been easier to get Emacs up and running on Mac than on Linux. To get the latest stable Emacs I had to pull the source and build it myself (Ubuntu repos had old versions). On Mac it was just finding the right cask in Homebrew.
The point is that you came in here with a pasted wall of text with a whole bunch of urls claiming emacs users on MacOS are somehow 3rd class citizens because ... of things from long ago, I guess.
My point, Don, is that these long-ago issues are now irrelevant. Your position here runs utterly counter to the lived experience of Mac emacs users.
I don't care what RMS did in 2005. It's not relevant to using emacs on a Mac in 2025.
I don't even need to care about the history of emacs on the Mac, or whatever other ill-advised chicanery the FSF has committed on this or any other point (and, not to put too fine a point on it, but at 55 I've seen plenty of goofy own-goals from that crowd).
What matters now is "gee, how easy is it for a Mac user to access and use emacs productively?" That answer, for at least the last 8 to 10 years (which is also the answer to your gatekeepy question), has been "very!" You open terminal and type "emacs," or you download a build that runs as a gui from any of several maintainers. You're done.
It's about as simple as it is to run it on a Linux box (which I also do), and far simpler than getting it to behave under Windows (and I have those scars, too).
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…
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
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.
The original terminal emulator terminal.el in gnu emacs, written by mly (Richard Mlynarik), was particularly salty. I finally tracked down a copy, but it looks like somebody complained and in 1990 it was begrudgingly cleaned up a bit, so some of the worst stuff was moved out into a separate file called term-nasty.el for posterity (you, here, now), so as not to give "in to the pressure to censor obscenity that currently threatens freedom of speech and of the press in the US" (oh, Richard <3 ):
;; disgusting unix-required shit
;; Are we living twenty years in the past yet?
(defun te-losing-unix ()
nil)
[...]
;; (A version of the following comment which might be distractingly offensive
;; to some readers has been moved to term-nasty.el.)
;; unix lacks ITS-style tty control...
(defun te-process-output (preemptable)
;;>> There seems no good reason to ever disallow preemption
(setq preemptable t)
[...]
;; I suppose if I split the guts of this out into a separate
;; function we could trivially emulate different terminals
;; Who cares in any case? (Apart from stupid losers using rlogin)
[...]
(?\C-b . te-backward-char)
;; should be C-d, but un*x
;; pty's won't send \004 through!
;; Can you believe this?
[...]
;; Did I ask to be sent these characters?
;; I don't remember doing so, either.
;; (Perhaps some operating system or
;; other is completely incompetent...)
[...]
;;-- Not-widely-known (ie nonstandard) flags, which mean
;; o writing in the last column of the last line
;; doesn't cause idiotic scrolling, and
;; o don't use idiotische c-s/c-q sogenannte
;; ``flow control'' auf keinen Fall.
"LP:NF:"
;;-- For stupid or obsolete programs
"ic=^p_!:dc=^pd!:al=^p^o!:dl=^p^k!:ho=^p= :"
;;-- For disgusting programs.
;; (VI? What losers need these, I wonder?)
"im=:ei=:dm=:ed=:mi:do=^p^j:nl=^p^j:bs:")))
[...]
(setq te-process
(start-process "terminal-emulator" (current-buffer)
"/bin/sh" "-c"
;; Yuck!!! Start a shell to set some terminal
;; control characteristics. Then start the
;; "env" program to setup the terminal type
;; Then finally start the program we wanted.
(format "%s; exec %s"
te-stty-string
(mapconcat 'te-quote-arg-for-sh
(cons program args) " ")))))
;;; term-nasty.el --- Damned Things from terminfo.el
;;; This file is in the public domain, and was written by Stallman and Mlynarik
;;; Commentary:
;; Some people used to be bothered by the following comments that were
;; found in terminal.el. We decided they were distracting, and that it
;; was better not to have them there. On the other hand, we didn't want
;; to appear to be giving in to the pressure to censor obscenity that
;; currently threatens freedom of speech and of the press in the US.
;; So we decided to put the comments here.
;;; Code:
These comments were removed from te-losing-unix.
;(what lossage)
;(message "fucking-unix: %d" char)
This was before te-process-output.
;; fucking unix has -such- braindamaged lack of tty control...
And about the need to handle output characters such as C-m, C-g, C-h
and C-i even though the termcap doesn't say they may be used:
;fuck me harder
;again and again!
;wa12id!!
;(spiked)
;;; term-nasty.el ends here
Note to the gentle readers: "wa12id" stands for "with a 12 inch dildo".
Of course, terminal.el is actually useful, albeit not terribly powerful.
(and terminal.el is pretty mild compared to some of the other things I've seen written by mly. :-))
Incidentally, a lot of terminal.el has been rewritten in version 19.
Too bad... I liked all the variable names and comments in the original.
Jamie Zawinski, Aug 5, 1992, 12:40:38 AM
In the FSF-distributed Emacs 19, the obscenities (will) have been stripped from terminal.el, though they are preserved in a file called term-nasty.el, to avoid appearing to bow to the censors.
In Lucid GNU Emacs, terminal.el will remain as nasty as it ever was.
-- Jamie "Truth, Justice, and the Fucking First Amendment" Zawinski
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.
Yes, it's definitely something you want to experience in the physical form! It's hard to describe what reading it feels like towards the latter parts of the book- you feel like you're lost in the book like how the Navidson gets lost in the house.
See, I feel like that in Emacs sometimes, too. The debugger helps.
I keep track of my Emacs with a Tractive GPS collar, and I have an app on my phone that shows the trails and a heat map of everywhere he's been. And I debug him with Frontline, but that doesn't prevent him from coming in with slugs in his fur. (Emacs is my cat's name.)
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 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.
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.
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'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.
I customized grep-find on my setup. I have a shell script so that it does the following (in typescript-mode)
first search ts, tsx, js, jsx files in the current project. Exclude .git, node_modules...
then search node_modules with the ts.. extensions, still exclude .git
finally search the whole tree for .py files still exclude .git, /dist...
This is coupled with consult-find-grep. I basically want to find a string in the most relevant file type. I never want a result from node_modules first in the results. It took some work, but the results are quite nice!
Oh, yeah, I wrote some Emacs Lisp that did that kind of project-specific thing for a Perl project I was working on for a couple of years in 02003 and 02004. One function key would search the whole project for occurrences of the identifier under the cursor, and another one would search for definitions.
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 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.
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
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.
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...>
Why should I bother, when I share James Gosling opinion regarding using Emacs on the 21st century?
https://www.linuxtoday.com/developer/dont-use-emacs-says-jav...
Given that was in 2008, I would update his remark from Netbeans, to any of JetBrains products, Eclipse or whatever.
In any case, you can get those features using Windows Resource Toolkit on the old days, a mix of findstr and other similar improvements on Windows NT linage, nowadays Powershell will be enough.
He’s probabaly just salty that his commercial Emacs clone for Unix (with its terrible not-quite-Lisp extension language) never took off.
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.
Oh sweet summer child.
http://xahlee.info/emacs/misc/emacs_macos_emoji.html
Color emoji was deliberately disabled on macOS (2016): policy first, parity later. Emacs 25 turned off multicolor fonts on the Cocoa port even though they worked, with a NEWS note saying they’d be re-enabled "once it is also implemented in Emacs on free operating systems." This was widely read as a political parity requirement that penalized macOS users for years.
https://www.gnu.org/prep/standards/standards.html
"Prefer GNU/GNU-Linux" development time: an explicit guideline. GNU’s own standards advise spending time on features "useful on GNU and GNU/Linux, rather than on supporting other incompatible systems." That guideline has often been cited in Emacs discussions to argue against platform-specific work that would land only on macOS.
https://irreal.org/blog/?p=13137
https://xenodium.com/emacs-send-to-aka-macos-sharing-merged-...
macOS-only features face extra process friction, or must be generalized. The "send-to" (macOS Sharing) patch was finally merged in 2025 -- but only after a lengthy debate and a rework into a cross-platform framework to satisfy GNU policy concerns about adding features that target a non-free OS first. (The end result is good! -- but the path illustrates the extra hurdles for macOS-first work.)
https://bitbucket.org/mituharu/emacs-mac
Long-running reliance on mac-specific forks to get a polished UX. For years, many mac users have depended on Mitsuharu Yamamoto's Emacs Mac port (emacs-mac) or distributions like Aquamacs to get native scrolling, gestures, font/rendering tweaks, and other integrations that either lagged upstream or weren’t accepted. The continued popularity and active maintenance of these forks reflects a gap in first-party mac attention.
https://xlii.space/eng/emacs-the-macos-bug/
https://news.ycombinator.com/item?id=44737676
Recent high-profile macOS performance pathology highlighted as "non-primary platform" pain. In 2025, a widely-read analysis ("Emacs: The macOS Bug") traced severe jank/memory growth to how Emacs drives Cocoa’s runloop (e.g., NSApp run usage inside the select/IO path), arguing that historical architecture -- plus macOS not being a primary target -- left deep issues unaddressed for years. Follow-on bug threads on emacs-devel discuss memory fragmentation and event handling. This is more engineering history than politics, but it shows practical consequences of platform de-prioritization.
https://www.gnu.org/philosophy/applying-free-sw-criteria
FSF position on non-free systems frames the culture. FSF materials repeatedly emphasize using and prioritizing free systems. Even where they explicitly say they didn’t drop support for non-free OSes, the values signal still affects triage, reviews, and what maintainers feel comfortable merging first. This shapes outcomes like color emoji support and the review friction in the "send-to" patch.
https://lists.gnu.org/r/emacs-devel/2012-07/msg00287.html
https://www.gnu.org/software/emacs/manual///html_node/efaq/N...
https://aquamacs.org/features/
https://lists.nongnu.org/archive/html/emacs-devel/2008-03/ms...
2008–2010, the long, bumpy road to a native Mac port: During Emacs 23’s cycle the old Carbon port was "completely broken ... for almost a year," and was ultimately removed when the new Cocoa/Nextstep port was merged. For years many Mac users relied on forks (Aquamacs, Mitsuharu's "Emacs Mac Port") for a smoother experience, reinforcing the "not a first-class target" vibe.
https://www.reddit.com/r/emacs/comments/bek5b2/til_emacs_was...
https://www.tuhs.org/pipermail/tuhs/2025-April/031758.html
https://github.com/SimHacker/NeMACS/blob/main/src/config.h#L...
RMS isn't only against Emacs on Macs and Windows. He also has some strong opinions about UniPress Software, who sold a version of Gosling's Emacs for Gosling's own NeWS window system, Apple Lisa, Mac, MS-DOS, Amiga, Xenix, SGI IRIX, Intergraph, xePIX, Northern Telecom, Cadmus, DEC Rainbow, VMS, VAX BSD, DECWRL Titan, TI Professional, Masscomp, Apollo, HP, Stride, AT&T 3B, System V, Gould, NBI U! ("Nifty Box"), Pyramid, Perkin-Elmer, Cray UniCos, and many other proprietary Unix systems.
https://news.ycombinator.com/item?id=28419139
>I worked at UniPress on the Emacs display driver for the NeWS window system (the PostScript based window system that James Gosling also wrote), with Mike "Emacs Hacker Boss" Gallaher, who was charge of Emacs development at UniPress. One day during the 80's Mike and I were wandering around an East coast science fiction convention, and ran into RMS, who's a regular fixture at such events.
>Mike said: "Hello, Richard. I heard a rumor that your house burned down. That's terrible! Is it true?"
>RMS replied right back: "Yes, it did. But where you work, you probably heard about it in advance."
>Everybody laughed. It was a joke! Nobody's feelings were hurt. He's a funny guy, quick on his feet!
I've got another one for macOS. It's not as significant as what you listed, but it was extremely annoying for me.
When using homebrew, the default package for emacs is version 30. However, that version on macOS was compiled with an outdated tree-sitter version (v14). If one tries to install a tree-sitter parser for a particular language it will not work with emacs 29 or 30 on macOS (or at least not that I could figure out). I tried the D12Frosted version and some of the alternatives for macOS (I forget the names).
The current tree-sitter project is on v15+, so in order for it to work, one has to go through the commit histories for each language and find when the tree sitter's parser version was last compatible with v14. To my knowledge, this was not clearly listed in all the git commits in a nice clean manner.
One alleged workaround was to install everything via RedHat OS and move the installed parsers over to macOS since their version of emacs and the tree-sitter parsers are still compatible. However, I was not interested in doing this.
Interestingly enough, Neovim does not have this issue on macOS to my knowledge, but I could be wrong.
Now, this is not entirely an emacs issue, but it does introduce an interesting issue. If emacs has to be compiled with a particular tree-sitter version, then it makes things quite difficult to maintain. The maintainers apparently are discussing various options on how to handle this going forward, but there isn't a clear way to work around this.
Now, I do believe if one builds emacs from source, he or she can work around this issue to some degree, but I was also not interesting in doing this because one loses out on some of the nice features that the macOS focused emacs versions come with. I also did not want to install all the dependencies required to build from source since those dependencies are not something I have any other use for other than building emacs.
So, I just gave up on the tree-sitter. Though, I think emacs 31 has this fixed until it happens again, but I also encountered a lot of other bugs when trying other use it since it's a prerelease version anyway.
This was all months ago, so maybe things have changed. I haven't kept up. I can live without tree-sitter for the time being.
Wow that's a wall of text proving pretty much nothing, other than that RMS is an out of touch goofball.
As I and others have noted, actually using emacs on a Macintosh is dead easy. MacOS ships with an older terminal version, so you don't even have to download anything if you're fine with that distro. OTOH, multiple native build distributions exist and are a click away.
I spend a good chunk of my day in a native build between text, scripting, and Orgmode, and, again, it's just not a problem. It's far easier, in fact, to use emacs on a Mac than on Windows precisely because MacOS is a unixy environment.
It only proves nothing if you didn't bother reading it (which you words "wall of text" imply) and didn't check any of the links proving what I said. Instead of dismissing everything by handwaving, please tell me which specific points I made that you disagree with, and what is your evidence?
How long have you been using Emacs, yourself? If you just got started a few years ago, then that excuses your ignorance of history (but not your unwillingness to learn), but there is a LOT of well documented history about Emacs on the Mac, and all those links you didn't bother following prove it.
You can't win an argument by being ignorant of history, claiming tl;dr, and refusing to look at the evidence. That's just conceding my points by default. Can you do any better than that?
It feels like this changed roughly in the last five years. That's about how long I've been using Emacs on Mac.
I'd mostly been using Sublime / Atom / Eclipse / Vim before that (and a long list of other IDEs and editors going back to Turbo Pascal 3.0 on IBM XTs). So perhaps I've not felt the same pain.
I'm glad I can use Emacs at work (on Macs) and at home (on Linux). The funny thing is it's been easier to get Emacs up and running on Mac than on Linux. To get the latest stable Emacs I had to pull the source and build it myself (Ubuntu repos had old versions). On Mac it was just finding the right cask in Homebrew.
>It feels like this changed roughly in the last five years.
Hmm, that's about how long ago RMS got "canceled" and resigned from the FSF board (September 2019). Go figure!
The point is that you came in here with a pasted wall of text with a whole bunch of urls claiming emacs users on MacOS are somehow 3rd class citizens because ... of things from long ago, I guess.
My point, Don, is that these long-ago issues are now irrelevant. Your position here runs utterly counter to the lived experience of Mac emacs users.
I don't care what RMS did in 2005. It's not relevant to using emacs on a Mac in 2025.
I don't even need to care about the history of emacs on the Mac, or whatever other ill-advised chicanery the FSF has committed on this or any other point (and, not to put too fine a point on it, but at 55 I've seen plenty of goofy own-goals from that crowd).
What matters now is "gee, how easy is it for a Mac user to access and use emacs productively?" That answer, for at least the last 8 to 10 years (which is also the answer to your gatekeepy question), has been "very!" You open terminal and type "emacs," or you download a build that runs as a gui from any of several maintainers. You're done.
It's about as simple as it is to run it on a Linux box (which I also do), and far simpler than getting it to behave under Windows (and I have those scars, too).
So what was your point again?
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)
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.
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.
https://news.ycombinator.com/item?id=36621699
The original terminal emulator terminal.el in gnu emacs, written by mly (Richard Mlynarik), was particularly salty. I finally tracked down a copy, but it looks like somebody complained and in 1990 it was begrudgingly cleaned up a bit, so some of the worst stuff was moved out into a separate file called term-nasty.el for posterity (you, here, now), so as not to give "in to the pressure to censor obscenity that currently threatens freedom of speech and of the press in the US" (oh, Richard <3 ):
[original broken link] https://opensource.apple.com/source/emacs/emacs-59.0.80/emac...
[term-nasty.el source] https://jason.zzq.org/git/emacs/plain/lisp/term-nasty.el?h=s...
1990-08-26 Richard Stallman (rms@mole.ai.mit.edu)
* terminal.el: Move possibly offensive comments to term-nasty.el.
https://www.digiater.nl/openvms/freeware/v10/emacs/common/li...
[...]
[...] [...] [...] [...] [...] [...] [...] [...]https://www.digiater.nl/openvms/freeware/v10/emacs/common/li...
Note to the gentle readers: "wa12id" stands for "with a 12 inch dildo".Jamie Zawinski kept Lucid Emacs nasty:
https://groups.google.com/g/gnu.misc.discuss/c/U5oXKOfWinQ/m...
Noah Friedman, Aug 3, 1992, 4:54:20 AM
In article <15i2n9...@hal.com> wood...@hal.com (Nathan Hess) writes:
>In article <FRIEDMAN.9...@nutrimat.gnu.ai.mit.edu>, friedman@gnu (Noah Friedman) writes:
>>It's by no means necessary, but it's funny.
>Along the same lines, look at lisp/terminal.el
Of course, terminal.el is actually useful, albeit not terribly powerful.
(and terminal.el is pretty mild compared to some of the other things I've seen written by mly. :-))
Incidentally, a lot of terminal.el has been rewritten in version 19.
Too bad... I liked all the variable names and comments in the original.
Jamie Zawinski, Aug 5, 1992, 12:40:38 AM
In the FSF-distributed Emacs 19, the obscenities (will) have been stripped from terminal.el, though they are preserved in a file called term-nasty.el, to avoid appearing to bow to the censors.
In Lucid GNU Emacs, terminal.el will remain as nasty as it ever was.
-- Jamie "Truth, Justice, and the Fucking First Amendment" Zawinski
[dead]
That he burned 11,000 words on his text editor tells you why emacs users are unemployable.
Now you mention it, come to think of it, I'm actually unemployed at the moment. We can't both be wrong!
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