Bare Metal (The Emacs Essay)(waxbanks.wordpress.com) |
Bare Metal (The Emacs Essay)(waxbanks.wordpress.com) |
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?
Emacs, too, is bigger on the inside.
I never thought that I can type just about any text, not in the input box of some app, but in my editor - with Emacs, if I need to type anything longer that three words - in Slack app, Zoom chat, browser window, etc., I'll do it in my editor, why have I never thought about this before?
Emacs has no business of taking screenshots, yet I use it to do just that - I'd insert a screenshot while taking notes, OCRing the text out of image when desired.
Before Emacs, I never thought of playing and controlling videos from my editor or driving my WM from it - I simply never thought how advantageous could that even be.
I can't really use anything else without feeling constrained specifically because [mostly] nothing else allows me to type some Lisp in just about any buffer, evaluate it in place and immediately affect not only my editor but any computational aspect on a local or remote machine.
In essence, Emacs is a mindset. Non-Emacs folk often don't see the "actual use cases" because their minds operate on a different plane. And for some, once they crack open that door of possibilities, there's really no turning back.
Writing Visual Studio, for example. Debugging Visual Studio. Extending Visual Studio in more than the ways it has already provided.
It means not being constrained to do only those things someone else had seen fit to permit you to do. It means freedom.
Such essential functionality like grep-find and LSP servers which is required for out of the box auto complete are not bundled with emacs. Most modern IDEs/editors have these functionality baked in.
If you install emacs for windows you find that grep-find doesn't work, because it depends on support from environment. A full text search should be built into the editor.
This is a robust and comprehensive antidote to nihilism and anyone who has ever missed the internet of the nineties or early 00s as I have would be doing themselves an enormous favour by reading it, and then rereading it as I intend to.
It lost me for a moment at Implicity and I was worried the spell had be broken but the profound blows didn't stop.
Later, in mid-2000's, the 3 DVD based Debian Sarge came with everything. Documentation, serious software, programming tools, mega nerd/geek games, the Anarchist FAQ, crazy fortune files, nerd lore and whatnot. You could snoop your BTTV and later DVB signals on the fly (even decode some channels my normal TV wasn't able to do), break tons of limits on cable TV sets (even override them)... it was magical.
Here’s the final two lines:
> We should know better than to prematurely optimize for order when all of all time arrowpoints in and down to the absolute return 0. Words of wisdom, let it be: your world is a fine stream of consciousness, lacking only a decent editor.
If that feels like your jam, go for it, but personally I feel in need of an exorcist after letting my computer load this…
When I open Emacs, it's like I'm five years old again, seated at my VIC-20, confronted with the infinite possibilities of the machine, challenged to explore them. Except the possibilities are so much greater because computers can do so much more and Emacs—as the programmable way to program—puts them virtually all at my fingertips. It's all a bit overwhelming, and this essay does a good job of capturing that overwhelm and the shift in perspective needed to cope.
That said, it's likely to send most people screaming back whence they came, clinging ever more firmly to their Visual Studio Codes and IntelliJs, if they be programmers at all and if not, it may turn them off programming altogether. Because that perspective shift looks like utter madness from the outside. I don't think we as a species are ready for computers yet. The possibilities, the implications.
Emacs w/org mode was the only program that helped me make sense of the mess and finish the darn thing. I have never seen a program so elegant and yet so powerful, and I am forever grateful it exists if only as a counterweight to the modern tech paradigm.
They say there’s no Emacs — only your Emacs.
My take personal takeaways from the experience:
1) capslock/ctrl switching is helpful in so many other areas - so I kept that
2) emacs is something you want to "live in" (e.g. learning to rely on eshell) if you want to really become proficient with it
3) emacs is something you have to be willing to tweak/adjust via elisp to suite your personal preferences if you want to really really really be proficient with it
I didn't hate emacs but it also wasn't for me.
3) I think the best way is to find some vanilla base config that will smooth out the rough parts, then, once you understand the internal concepts, tweak them to your liking. It's certainly a long term plan, but the pro is not having to wait on "features" from another company or group.
For years, I had a similar feeling about it. And then I learned that in eshell you can pipe in and out of buffers. So you can for example grep the content of one buffer and pipe results into another. Or pipe the output of a command to a buffer, and you even can chain them pipes. That often comes extremely handy.
Or vterm if you don't want to be proficient with eshell.
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.
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
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
Your words, not mine. But gene propagation is up there, and steady wages is a sufficient if not necessary condition for that to happen.
They could at least change the default theme to one of the already-bundled modus-themes or something.
Out of the box, project and context aware auto complete is an essential feature in a modern IDE.
Apparently I've sometimes improvised an equivalent: "Run grep via find, with user-specified args COMMAND-ARGS. ... This command uses a special history list for its arguments, so you can easily repeat a find command."
My out-of-the-box autocomplete is M-/, which works in environments where LSP doesn't, like writing English. It works sort of poorly in all of them, but I write production code slowly enough that my typing speed isn't close to being a bottleneck. It's more of a bottleneck when writing English, but even there, generally any of my good writing was good rewriting.
Where I've found LSP-like functionality really useful in the past in IDEA and later Eclipse was not autocomplete, which is mostly an annoyance, but in automated refactoring (extract variable, extract method, inline method) and in rapidly iterating through the implementors of a method whose semantics I'm changing.
Ardour has around 800k lines of code, and ag (not even the fastest of the new greps) can search it all more or less faster than I can type.
The idea of some system that analyzes/caches/indexes the code just isn't necessary anymore.
There are plenty of emacs "starter kits" that do aim to provide more of a batteries included experience. My favorite is doom, it's worth checking out and does setup all the features you mention.
Pointing new users at those more advanced default configs as an option would be pretty helpful, I think.
- have result that can be formatted in a tabular fashion
- do stuff with files then present some diagnostics (especially if errors and warnings are related to the files)
- Have an REPL interface
It’s not preconfigured like VS Code, but it’s much more versatile. Cursor having to fork VSCode is one such example. In Emacs, anything is just another package.
The reason there aren't programmers targeting the large market is a tangent into why I'm building PrizeForge, but the answer now doesn't change.
https://www.gnu.org/software/emacs/manual/html_node/emacs/Gr...
You can change the exec-path to point to your cross compiled grep tool --- or you can change the command string to your tool of choice.
- result on standard output - path and line numbers on each line
A lot of emacs reliance on other tools follow the same pattern. While the default is posix, it has enough options to twist it to fit whatever OS.
There are ways to search and grep files on Windows.
The only one I've ran into that is different is Java, but considering how underdeveloped Java LSP servers are, you probably don't want to be using emacs for Java development.
IDEs with such capabilities were already available in the 1990's.
I became an XEmacs user in the 1990's, because there was hardly anything better in UNIX systems.
Remember, Emacs still lacked many niceties only available on XEmacs, and vim was yet to be invented.
This is how old such IDE features have been available.
...you are a second class citizen in the emacs republic.
I mean, I don't endorse this position, but it's the way things are.
...you are a third class citizen in the emacs republic.
In spite of the fact that you can't spell emacs without mac.
Also:
>If you install emacs for linux...
...you get flamed for not calling it gnu/linux.
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.
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
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.
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.
In fact, in was the opposite.
So what are you even talking about?
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.
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, that would be pretty awesome. The GIMP tries to be something like that.
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.
we're here to edit text though, I thought? It sounds clever but it might be clever for clevers sake sometimes.
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.
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.)
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!
(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"
Doing the three searches separately and exiting after one succeeds is only slightly more code.
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.
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.
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!
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.
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.
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.
such as?
>I can edit the URL of any tab in my browser directly from my editor
i give up.
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?
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.
Hmm, that's about how long ago RMS got "canceled" and resigned from the FSF board (September 2019). Go figure!
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?
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.
theres a bit of the pot calling the kettle black there
I apologize for dragging you into it.
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?
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?"
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.