Bare Metal (the Emacs Essay)
Posted3 months agoActive2 months ago
waxbanks.wordpress.comTechstoryHigh profile
calmmixed
Debate
60/100
EmacsText EditorsProductivity
Key topics
Emacs
Text Editors
Productivity
The essay 'Bare Metal (The Emacs Essay)' is a philosophical and nostalgic exploration of Emacs, sparking a discussion about its strengths, weaknesses, and the culture surrounding it.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
6d
Peak period
64
Day 7
Avg / period
16.6
Comment distribution116 data points
Loading chart...
Based on 116 loaded comments
Key moments
- 01Story posted
Oct 14, 2025 at 4:50 PM EDT
3 months ago
Step 01 - 02First comment
Oct 21, 2025 at 4:31 AM EDT
6d after posting
Step 02 - 03Peak activity
64 comments in Day 7
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 30, 2025 at 9:48 AM EDT
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45584680Type: storyLast synced: 11/20/2025, 4:56:36 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Such essential functionality like grep-find and LSP servers which is required for out of the box auto complete are not bundled with emacs. Most modern IDEs/editors have these functionality baked in.
If you install emacs for windows you find that grep-find doesn't work, because it depends on support from environment. A full text search should be built into the editor.
They could at least change the default theme to one of the already-bundled modus-themes or something.
Out of the box, project and context aware auto complete is an essential feature in a modern IDE.
There are ways to search and grep files on Windows.
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.
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.
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.
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.
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.
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!
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.
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.)
...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.
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.
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.
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.
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.
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.
Here’s the final two lines:
> We should know better than to prematurely optimize for order when all of all time arrowpoints in and down to the absolute return 0. Words of wisdom, let it be: your world is a fine stream of consciousness, lacking only a decent editor.
If that feels like your jam, go for it, but personally I feel in need of an exorcist after letting my computer load this…
I 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.
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.
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.
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.
theres a bit of the pot calling the kettle black there
such as?
>I can edit the URL of any tab in my browser directly from my editor
i give up.
Yes, that would be pretty awesome. The GIMP tries to be something like that.
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.
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
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.
https://www.youtube.com/watch?v=urcL86UpqZc
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.
Your words, not mine. But gene propagation is up there, and steady wages is a sufficient if not necessary condition for that to happen.
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.
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.
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...
[...]
[...] [...] [...] [...] [...] [...] [...] [...]https://www.digiater.nl/openvms/freeware/v10/emacs/common/li...
Note to the gentle readers: "wa12id" stands for "with a 12 inch dildo".Jamie Zawinski kept Lucid Emacs nasty:
https://groups.google.com/g/gnu.misc.discuss/c/U5oXKOfWinQ/m...
Noah Friedman, Aug 3, 1992, 4:54:20 AM
In article <15i2n9...@hal.com> wood...@hal.com (Nathan Hess) writes:
>In article <FRIEDMAN.9...@nutrimat.gnu.ai.mit.edu>, friedman@gnu (Noah Friedman) writes:
>>It's by no means necessary, but it's funny.
>Along the same lines, look at lisp/terminal.el
Of course, terminal.el is actually useful, albeit not terribly powerful.
(and terminal.el is pretty mild compared to some of the other things I've seen written by mly. :-))
Incidentally, a lot of terminal.el has been rewritten in version 19.
Too bad... I liked all the variable names and comments in the original.
Jamie Zawinski, Aug 5, 1992, 12:40:38 AM
In the FSF-distributed Emacs 19, the obscenities (will) have been stripped from terminal.el, though they are preserved in a file called term-nasty.el, to avoid appearing to bow to the censors.
In Lucid GNU Emacs, terminal.el will remain as nasty as it ever was.
-- Jamie "Truth, Justice, and the Fucking First Amendment" Zawinski
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.
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.
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.
6 more comments available on Hacker News