Bare Metal (The Emacs Essay) | Hacker News Reader

Bare Metal (The Emacs Essay)

waxbanks.wordpress.com

202 pointshpaone122 comments

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.)

Is he bigger on the inside? Does he represent a bet that didn’t pay off, on a future that will never, ever be allowed to come? Does he embody the charming but mistaken belief that creating tools to make people freer will begin a movement toward freedom?

"I've also been diagnosed with severe hostility towards Vim users but that's not a real disease of course. The real disease is Vim."

https://www.youtube.com/watch?v=urcL86UpqZc

Silly. The only people who are hostile to Vim users are vi users, because Vim is a vi clone that is secretly Emacs.

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!"

Oh, did he stop?

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 have never once thought Visual Studio needs some way to edit its own source code on the fly... whats the actual use case?

Good question, you may have to be the ultimate power user to need this feature? What are those people doing?

Vibing. It's a state of zen and connection to the technology that you use.

anything. we're doing anything.

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.

> Non-Emacs folk often don't see the "actual use cases" because their minds operate on a different plane.

youve just listed a bunch of scripts launched from emacs. with your logic, you can take the lisp interpreter out of emacs, stick it into say mspaint, and have an equally powerful program.

Yes, it may sound like that to someone unacquainted with it. But have you ever thought about the reasons why Emacs remains relevant and triumphant even half a century later?

Here's really fascinating stuff: I can start a fresh new instance of plain, vanilla, clean-slate instance of Emacs; then open a scratch buffer and piece-by-piece rebuild my entire configuration, consisting of a dozen thousand lines of customizations; install third-party packages that bring hundreds of thousands of their own code; I can do that by evaling every expression one-by-one without not only having to restart Emacs even once, but even not needing to save that code anywhere. How many applications can you name that are capable of pulling a trick like that?

Sure, that may sound impractical, let me give you another, real-life example: I needed to change how Google Translate [extension] works - I wanted it to translate year denominations (to learn exactly how they spelled in a foreign language). Did I have to dig through the Google API docs? Nope. Did I have to write my own custom extension? Nope. Did I even have to re-implement the function that sends the payload? Once again, nope. I just had to precisely advise a single function and convert digits to words before sending the payload, something like eleven lines of code. And it took me no longer than fifteen minutes. Good luck trying something like that in pretty much any other editor.

So, yeah, getting exposed to that kind of power does change your mindset.

> I can start a fresh new instance of plain, vanilla, clean-slate instance of Emacs; then open a scratch buffer and piece-by-piece rebuild my entire configuration, consisting of a dozen thousand lines of customizations; install third-party packages that bring hundreds of thousands of their own code;

we're here to edit text though, I thought? It sounds clever but it might be clever for clevers sake sometimes.

> we're here to edit text though, I thought?

It seems you're missing the point - that example is 'reductio ad absurdum' - a showcase of the logical extreme of capabilities, not an illustration of concrete practicality.

You seem to be blinded by your sunk cost, social proof, tribal identity, status quo, and other biases, so you rather reject novel ideas than accept their practical superiority in certain scenarios.

Emacs, in every respect, is a pinnacle of text editing in its digital form. Half a century of evolution and refinement with fundamental architectural advantage - a Lisp runtime that happens to edit text.

It makes it possible to edit any text that lives within its running instance and beyond - just about anything it can reach - containers, kubernetes pods, browsers. I can edit the URL of any tab in my browser directly from my editor; remote computers - I can edit a commit message on an EC2 instance; heck, even spacecrafts a million miles away - if it can gain access. More than that - there's universal bidirectionality - I can push any text into Emacs - from my terminal, my browser, or any app. If I allow access to it, I can even push to Emacs from remote computers.

I'm, by the way, not an 'Emacs purist' - I use Neovim daily, and sometimes VSCode too. I have used various JetBrains products - I was a heavy user of IntelliJ for almost a decade. Yet, getting exposure to Emacs capabilities proved that I was wrong in my prejudice and I should've tried it sooner. Like I said: it's a mindset-changing endeavor - without a heartfelt attempt to use it, it's unlikely you'll ever get what I'm even talking about.

If I could get you access to a spacecraft a million miles away, would you stay there and never come back?

Do you really have to be a jerk? Or you were dropped in your infancy and you just can't fucking help it? Go seek some professional help maybe, it really hurts to see someone being so miserable.

> Go seek some professional help maybe, it really hurts to see someone being so miserable.

theres a bit of the pot calling the kettle black there

Yes I lost my cool for a moment, we have a history with that HNemer. He made it his full-time job to troll, to the point that it makes me want to stay away from engaging any conversations on this site.

I apologize for dragging you into it.

You're not the pot calling the kettle black, but please don't respond in kind to people like that ... if you simply ignore him and those like him (I know, it's hard) then your engagement with reasonable people shouldn't be affected.

https://news.ycombinator.com/newsguidelines.html

> It seems you're missing the point - that example is 'reductio ad absurdum' - a showcase of the logical extreme of capabilities, not an illustration of concrete practicality.

such as?

>I can edit the URL of any tab in my browser directly from my editor

i give up.

> with your logic, you can take the lisp interpreter out of emacs, stick it into say mspaint, and have an equally powerful program.

Yes, that would be pretty awesome. The GIMP tries to be something like that.

> I have never once thought Visual Studio needs some way to edit its own source code on the fly... whats [sic] the actual use case?

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.

> Extending Visual Studio in more than the ways it has already provided....It means freedom.

if youre able to edit the source code of a program, youre probably a programmer. you already had the freedom. and that can be done with git and the offline source code. its not freedom its convenience if anything

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.

Except pycharm won't work with my erlang lsp.

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.

Why not instead blame Windows for not having the standard tools “grep” and “find”?

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.

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.

Calling Gosling "the father of Emacs" is pretty inaccurate. What Gosling did was create the first UNIX version of Emacs, and while that predates RMS' GNU Emacs, Emacs was originally a series of macros created by RMS for the TECO editor running on ITS (Emacs originally meant "editor macros"), so RMS is clearly the father of Emacs.

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.

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

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.

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.

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.

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 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.

Would you mind sharing how you did the prioritization of the sources when searching?

Not the original poster, but if I were doing it with find rather than fd (or ag or rg, which I think can do it without fd or find) I'd do (untested)

    (find "$projroot" -name .git -prune -o -name node_modules -prune -o \
         \( -name '*.[tj]s' -o -name '*.[tj]sx' \) -print0 ;
     find "$projroot"/node_modules \
         \( -name '*.[tj]s' -o -name '*.[tj]sx' \) -print0 ;
     find "$projroot" -name .git -prune -o -name dist -prune -o \
         \( -name '*.py' \) -print0 ) |
    xargs -0 grep /dev/null "$search_pattern"

And, although that approach does work (and maybe even that script will work without any bug fixes) it probably goes a substantial distance toward showing why fd was written.

Doing the three searches separately and exiting after one succeeds is only slightly more code.

https://github.com/paddymul/emacs-from-scratch/blob/master/p...

and

https://github.com/paddymul/emacs-from-scratch/blob/master/p...

The emacs-lisp for changing the behaviour of consult-grep was quite complex and took a while to write.

>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.

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.

take it up with the fundamentalists, I'm a Mac Emacs user.

Ah, fair. Me too.

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!

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?

My thoughts too. I've never had any real problems running it on Windows myself, but it doesn't feel like Mac users are any worse off.

I've been using Mac Emacs since about 2010, so perhaps I dodged some of the worst stuff, and it's always felt - for good or for ill - very much the same as using it on Windows or Linux/X-Windows, both of which I've been using since 2005 or so.

I've always used the standard GNU version rather than any specific Mac port. Over the years I'll have done some mix of downloading prebuilt binaries, building it from source, or getting the MacPorts version.

Perhaps I have missed out on some Fancy Extra Mac Stuff, the sort of thing that would come as standard with any project that took the platform seriously, but it's never really felt like a problem. And indeed, I figure if I'm happy enough with it running on X-Windows and on Windows, why wouldn't I be just as happy with exactly the same thing on macOS too? A consistent (or near enough) cross-platform experience is part of why I use Emacs anyway.

My sweet summer child.

This isn't much of an argument, Don. Just being condescending may be charming somewhere else, but here it just looks like you're being a jerk -- and a jerk without much that's relevant to add to the conversation.

Do you really believe that RMS has suddenly done a 180 and changed his core beliefs and philosophy about Apple and Macs and non-free operating systems?

Do you even know him, have you ever talked with him about free software or copyleft, have you ever even read anything he's written? Are you brand new to this whole "free software" thing, and it's a total shock to you that RMS has a long standing opinion about supporting Macs and other non-free operating systems?

It's obvious you haven't read any of the links to evidence I posted, or even anything RMS has written about the subject, but you really should do some research before jumping to such historically uninformed conclusions.

Parading your self cultivated ignorance and unwillingness to read, enumerating things you don't care about, and refusing to indicate what I wrote that you disagree with or provide any evidence to the contrary after I asked you to, just isn't a good look, and won't win any arguments that I have nothing to add to the conversation.

One more time: what evidence I gave do you disagree with, and what evidence do you have than RMS has done a 180 and abandoned his long held principles? Do you even know what those principles are?

RMS is functionally irrelevant to the experience of someone on a Mac who wants to use emacs, because -- Again! -- all you have to do is download a build and you're off to the races.

That's the end of the discussion. It doesn't matter what RMS' position is. (And yes, I know what those are -- and no, I've never spoken to him, because I tend to avoid creeps.)

emacs is free software that, once released to the world, will find its way into many places perhaps its most famous proponent would prefer it not. And this happens because his opinion is irrelevant. This has happened before. This will happen again. RMS being a sad puppy about Macs and Windows doesn't change the fact that many, many folks have productive emacs-centered computing experiences on those platforms. He can die mad about it.

You posted a shitton of material, but none of it addressed the simple fact that using emacs on a Mac is approximately as easy as using it on (e.g.) Debian. There's no real difference for most use cases.

I'm not in the habit of taking homework from gish-galloping boomers hell bent on missing the point, so I'm not going to answer any of your questions. I will, however, note that I'm far from the only person in this thread looking at you and thinking "what the hell is this guy on about?"

Your litany of butthurt actually bolsters my opinion of the bozos at emacs-devel, who I've long criticized for hypocritically advancing emacs on proprietary os's despite their ostensible mission to destroy them.

You seem to think there is only one version of Emacs, and that its entire monolithic developer community is totally unified in its opinion and philosophy and mission, so you can accuse the entire community of being hypocritical if there is any dissent or diversity or competition.

I just wrote a long list of proprietary operating systems one version of Emacs ran on, and even linked to the source code proving it, which RMS opposes so vehemently that he calls it "Software Hoarder Emacs", and jokingly accuses its developers of burning his house down.

If you really think RMS's mission to destroy all non-free operating systems is "ostensible", you definitely don't know him or his reputation.

>ostensible /ɒˈstɛn(t)sɪbl/ adjective: stated or appearing to be true, but not necessarily so.

You're overcomplicating this. If RMS and his lackeys were so hellbent on ridding prop OS's from the world, they could move marginally closer to that goal by simply deleting w32* ns* and android* from GNU Emacs. That they instead collectively spend several man-months per year stressing about their upkeep means they care more about expanding their userbase than any bullshit notion of "freedom."

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.

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.

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!

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.

the total lack of “getting it” on display here is simply flabbergasting.

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.

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…

Author is a lapsed Catholic, it checks out (speaking as a former lapsed Catholic who knows lapsed Catholics)

Under Unix the norm is to return 0 if everything it's OK.

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.

  They say there’s no Emacs — only your Emacs.

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

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.

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.

I've been using emacs for over 20 years and had no idea about `M-x tetris`. Worth reading just for that!

M-x dunnet too.

And,if you are into text adventures, there's M-x dunnet and, also, malyon under MELPA, and you can play some good ones such as the ones from Infocom, or the modern ones made from the community such as Tristam Island, Anchorhead, Spider and Web, Spiritwrak... the IF archive has them all (on Tristam Island, I can send you a better ZMachine V5 version, instead of a shortened V3 one made for the 3rd version of the Z-Machine, the one for small microcomputers such as the C64, MSX, the 8086, the Kaypro with CP/M 2.2...)

And, if you are curious, you can install the inform6 compiler and inform6lib (the English grammar library) and, under Emacs, inform-mode and create your own text adventure in a very easy OOP like language (inform6), much more than Python.

Inform Beginners' Guide: https://inform-fiction.org/manual/IBG.pdf DM4, the low level stuff, raw inform6 without the English library. Advanced stuff: http://inform-fiction.org/manual/download_dm4.html

Creating a text adventure might look silly in these times, but if you pay attention to the article, it's these kind of environments what changed the world back in the day, from MUDs/MOOs to roguelikes (in the case or Rogue, literally). Curses was a library to play Rogue and update the terminal lest often (just send what changed in the screen to the terminal) so the connection wasn't cluttered back in the day with frequent menu displaying where the changes were minimal.

With Inform6 you don't need to be a music composer, a drawing artist or some 3D modeller with tons of linear algebra background. Just write.

And, yes, it can be loads of fun with very little. Look how easy can be the old 'advent' game under Inform6:

https://www.ifarchive.org/if-archive/programming/inform6/exa...

The game itself in order to be played with M-x malyon:

https://www.ifarchive.org/if-archive/games/zcode/Advent.z5

Now compare it to the C ports under BSD's or GNU/Linux.

I had to use Emacs eww to read the article :)

I'm using Emacs to read these comments. Because... why not?

true, why not. I was making a funny comment to let people know eww works.

Haha. What's really cool about eww, that you can just open any page, and then change the major-mode of it - I read org-mode, markdown readme's like that, or explore CI logs, etc.

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...

[...]

    ;; 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) " ")))))

[...]

    ;;;; what a complete loss

[...]

https://www.digiater.nl/openvms/freeware/v10/emacs/common/li...

    ;;; 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".

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

Maybe if it weren't for the above ranting, POSIX wouldn't have gotten its shit together to clean up the terminal situation and come up with the <termios.h> stuff.

Today I have a way of using <termios.h> stuff to even control the Windows cmd.exe console.

It's the most portable thing there is for getting clean character-at-a-time input, with Ctrl-D and everything.

That he burned 11,000 words on his text editor tells you why emacs users are unemployable.

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

The opposite is also true. I have never heard anyone climbing the ladder specifically because they are "so fucking good" with [insert whatever IDE/editor]

Dude is saying nonsense. "Emacs users are unemployable" sounds like "Tesla drivers unregisterable" - what an imbecilic, utter bullshit that has zero sense to say. Ever.

The implications behind gene propagation being one of the highest achievements a person can aspire to are quite unfortunate to consider.

Regardless, I don't think anyone is going to, say, avoid a specific doctor because said doctor is fond of Emacs. Same for a plumber, a baker, an electrician, a lawyer, et cetera. As a matter of fact, I have a hard time thinking of any profession where a fondness for Emacs may be considered a bad thing. Perhaps a software developer may have a harder time finding gainful employment if potential employers find out about the preference for Emacs, though that would likely only be an issue among a limited and specific set of potential employers.

I'm an employed emacs user and more than half of my team also uses emacs

Now you mention it, come to think of it, I'm actually unemployed at the moment. We can't both be wrong!

I worked at 3 universities and one multi-national company over 30 years. I used Emacs at all of them. I'm retired now, and still use Emacs daily.

Reply on news.ycombinator.com