> A common refrain is that Emacs is an operating system (OS). This isn’t true, but what invites comparison to an OS is its ability to orchestrate applications and utilities above the OS kernel level.
Only because Lisp Machines, or variations thereof didn't took off in the mainstream.
Even if LISP machines took off, an editor running on them still would not be an OS. Such claims come from people who don't understand what a platform is and who can conflate any platform with an operating system. You also see these people calling web browsers operating systems. By this flawed definition you could even call things like Roblox an operating system.
As long as you don’t care about interlanguage interop, sure. The opposite point of view, that every language tries to become an operating system (and consequently to prevent other languages from coexisting), is also possible, and I’m somewhat more sympathetic to that one.
Given his work on Smalltalk, I suspect he means that he prefers the line between language runtime and operating system to be erased, and they be the same thing.
I disagree though. While there are benefits to that approach, I feel like language innovation would be stifled to a certain degree.
I learned a while ago that eMacs is more like a programming environment that has a text editor built in. Sort of like some SmallTalk images. When you think of it this way it’s pretty neat.
I've been an Emacs user for over 25 years. But last year I switched employers and they won't let me use it even for tasks where it would absolutely shine. Their argument is that all team members should use the same tools, and I guess that is a valid point.
Unfortunately, I failed to convince my employer to make everybody else switch to Emacs.
So, now I'm using lots of one-purpose tools, one for each separate task, a good deal less efficiently than I could use Emacs, and I'm still learning all the new UIs and keyboard mappings.
At a company I work for, they are doing various changes (and control) over the software we install as we transition to a larger company. I believe they are using Microsoft Intune so they can allow/deny what can be installed.
I have not updated my laptop (or got a new one) because I am concerned they will not allow me to install or continue to use Emacs. Honestly, I can vision how that conversation goes:-
[manager]: Hi, so what is Emacs
[me]: Emacs is a text editor I use daily and makes me efficient in my work
[manager]: OK. I would like us to start using Visual Studio Code with the new projects coming up
[me]: Why? The consumption models we are using has no VSCode support, anyway.
[manager]: It would just be good if we are all using the same tools
[me]: It should not matter what we use as long as we work with git and deployment. If someone else is great with a different text editor why force them to use something else?
[manager]: (Looks up emacs)
[manager]: I think its best we stopped using it because it is not supported by Microsoft and we need to be careful with the dangers of open source.
[me]: OK. Should we contact other IT departments to replace any open source tools they use?
[manager]: Its just emacs is not verified software for the business. I think you are complicating things a little (tries to belittle me)
[me]: Emacs is my daily driver! If it goes, I will hand in my resignation!
* Manager is not there to understand or reason.. he is just following orders from other IT departments. *
I scheduled my intune upgrade when I needed a week off for doing house moving stuff. I was told Emacs would work, didn't. Took them about a week before I could use it again.
I worked briefly in public administration at one point in my career. I asked the admins the same thing, could I get Emacs installed on my machine. I got a bit concerned when the admin staff asked back: "What is Emacs?"
In my case, I am a very senior member of my team so 25-50% of each day is spent helping and/or teaching teammates. In situations like that, it is useful to be deeply familiar with the tools that your teammates are using so you can tell them exactly what to do.
For example, if I'm teaching a new hire to set up their vscode it is not very helpful to tell them "now you need to activate the python venv". It is much more helpful to be able to tell them "Now we're going to activate the python venv. To do that, open your command palette and search for 'select python interpreter'".
In my personal life, I still exclusively use emacs (which I have scripted to auto-detect venvs) but I put up with using vscode at work to be a greater utility to my team.
The point of the parent is that in an ideal situation, where everything works without flaw, theoretically it makes no difference which tools everyone uses. In real life, you having a homogeneous setup across a team makes the sysadmin's job a lot easier.
> Their argument is that all team members should use the same tools, and I guess that is a valid point
No. That's only a valid point if something about the tool must be shared between users, rather than just the output. Emacs is a text editor. It reads, modifies, and produces text. The correct tool for each team member to use is the one they're most productive with, full stop.
Jesus fucking Shiva while Odin watches, but I hate corporate management "thinking". It's just become more and more brain-dead over the decades.
> why would you disobey a direct instruction from you super?
Because the instruction was stupid, based on marketing instead of utility, or otherwise given without any thought to how it impacts the actual day-to-day work of their subordinates.
Why WOULDN'T you disobey a stupid instruction? What's the difference between "stop using this tool you're productive in and switch to this one that you're demonstrably LESS productive in for no reason other than I heard it was a good idea", and "Go strap some rocks onto your ankles and swim the English channel. I heard that was a good idea."?
This just proves that you can cram pretty much anything into the client/server dichotomy if you just define "client", "server" and "request" broad enough. Similarly, I remember how desperately people tried to argue that Emacs follows the "Unix philosophy" as long as your LISP functions are doing just one thing, and do them well.
I don't know what you would gain from these things. Emacs follows the idea of LISP machines, I think that much anybody can agree on. From there, Emacs can be or do pretty much whatever you want. It's excellent in communicating with CLI tools - you can call that client/server if you want, but I wouldn't know what you'd gain from that definition. The reality is that Emacs has gone through a lot of fads and hypes over its decades of existence, and each time, it has taken something along the way. Heck, there's a whole semantic parsing engine buried within (CEDET), which nowadays is pretty much unused, because then LSPs came along, and now we have agents (which Emacs btw is a pretty decent frontend for).
One of the pivotal moments in my career has been when I used Emacs just enough to truly understand what "Emacs is an operating system" means, not just as a joke but as something I could believe in
But you already had an operating system and you could already code... Did Emacs really give YOU any capability you didn't have before? Don't forget this is a text editor, not an IDE or some general purpose automation harness
You could add lisp to mspaint and mspaint suddenly becomes awesome somehow? I don't follow the logic
I think of Emacs as more of a lisp machine than text editor. I'm also not sure what an IDE has over Emacs. I have autocomplete, compiler checks, and run tests all within Emacs.
For general automation, my blog is built with Emacs Lisp.
It sounds like you think emacs is some sort of basic text editor, I dunno, like Notepad on Windows, that has an adjoined Lisp interpreter?
Emacs is a 42-year-old software program that has been in constant development this entire time. Its git repository has over 180,000 commits right now on its main branch, which is still 20,000 ahead of VSCode. It doesn't just have a Lisp editor attached, it has 1.6 million lines of Lisp in it as well, and that's just the source repo, not all of the extensions you can get for it. Using "cloc" to count the total lines of source it has, it's still pretty close to 2/3rds the lines of code than VSCode has.
Yes, it gives you a lot of capabilities you didn't have before. The joke about it being a decent OS that needs a good text editor comes from the fact it has a large number of things it can do out of the box that aren't just text editing. It isn't just Notepad with a Lisp interpreter attached. It has vast capabilities that have been implemented and then also tested over the course of decades. Considering the set of disadvantages it carries with it, like weird key bindings and the fact that the variant of lisp it uses is more-or-less unique to emacs, somewhat analogously to the handicap principle [1] one should counterintuitively understand that as a sign that it must have extraordinary strengths that are able to offset that.
(I've used it for a long time, but I never really learned Lisp. AIs are making it much easier to customize than ever, though. I've said many times here on HN that I think every line of AI code should be reviewed. So yesterday I prompted Claude to build some Lisp functions so I can declare 1. a base directory 2. a regex of file names to match and produce 3. a function to walk over the entire directory forwards or backwards with CTRL-x CTRL-n or CTRL-x CTRL-p, thus allowing me to easily walk through an entire project for review purposes systematically. Nobody had to give me permission to do that. I didn't need to "create an extension". I don't have to care if anyone else in the world wants it. It's not the only editor that can do this as easily as emacs but it's a short list.)
> Don't forget this is a text editor, not [a] general purpose automation harness
This arguable. I personally use emacs for text editing for sure, but not only: it also does emails (notmuch), git (magit), team & project management (org), mastodon, fleet management (nix + colmena + custom elisp functions), and, more importantly, all these “applications” can mutually share data.
So can you use emacs as a text editor only? Sure. Can you leverage its intrinsic abilities to reach what might be called an automation harness? Yes as well.
It certainly did for me, because it let me trivially write code that integrates deeply into the rest of the system.
A simple example: I wrote a function that let me highlight an X.509 cert in a YAML document, regardless of indentation, and pass it to 'openssl x509' to show me what it is. This has saved me lots of time over the years not having to copy/paste, fiddle with whitespace, etc. But it's only valuable because the functionality is now right at my fingertips in the environment I'm already in!
The Emacs API is kinda huge, with things like very raw network API, a very good approximation of fork/exec process management, buffers as the base communication mechanism with a lot of capabilities, various utility function with regards to interfacing with the user (windows, frame, faces, keyboard events), then the hooks and advice subsystem.
With Unix, most programs are binary and while the shell is a good glue language, you can’t alter a program and the OS that much. With Emacs, only the core coded in C is sacred, anything else can be modified to fit your workflow. And there’s a lot of packages out there to provide you with raw materials.
I've been on spacemacs.org for a while, but since I've got a Keychron G6 Pro where I can reprogram the caps lock, I'm going to try out some hard-core init.el stylings.
I also started on spacemacs but then I wanted to learn the basics of it and switched to writing my own configuration from scratch.
What helped me the most is reading though the Mastering Emacs book by Mickey Petersen which is an amazing resource to learn the basics and beyond.
Right now I'm in the process of reducing the number of external packages I use and I'm trying to use more of the built in functionality that is available "out of the box".
I see shell as an instrument through which you use other tools. In that sense, vi feels much more like a shell, because you have to use other standard unix programs with `:.!` for much functionality.
Where Emacs comes with all bells and whistles included in one big distribution, much like an operating system.
Something that undermines the operating system angle is that emacs does not implement hardware drivers. All interaction with the systems goes via system calls.
Norton Commander contains a text editor. Emacs operates at that level, whilst being reprogrammable.
I did not get this argument. Diagrams are nice, and I probably missed something in lisp code (not used to lisp syntax), but I see no argument that Emacs has more service-like interaction with other apps or its plugins than say vim or vscode. I agree that emacs is the most OS-like, but I would love if someone explained what exactly is the point in the article
In Emacs, everything looks like a part of the core system. The whole thing is just one unvariegated blob of Lisp, which could be a strength or a weakness depending on your perspective. Me, I happen to like that sort of thing.
Only because Lisp Machines, or variations thereof didn't took off in the mainstream.
"Symbolics Lisp Machine demo"
https://www.youtube.com/watch?v=o4-YnLpLgtk
"Emacs and Lisp"
https://funcall.blogspot.com/2025/04/emacs-and-lisp.html
While Emacs was forked by Lucid as XEmacs to make one of the very first ideas of LSP, nowadays most features have been integrated back into Emacs
https://dreamsongs.com/Cadillac.html
"Lucid Energize Demo"
https://www.youtube.com/watch?v=pQQTScuApWk
-- Dan Ingalls
To run? Absolutely not.
Edit: Looking up the quote it seems to just be the person being pedantic in how they define operating systems.
I disagree though. While there are benefits to that approach, I feel like language innovation would be stifled to a certain degree.
What a surprise
Pragmatism beats idealism in the real world
Unfortunately, I failed to convince my employer to make everybody else switch to Emacs.
So, now I'm using lots of one-purpose tools, one for each separate task, a good deal less efficiently than I could use Emacs, and I'm still learning all the new UIs and keyboard mappings.
I have not updated my laptop (or got a new one) because I am concerned they will not allow me to install or continue to use Emacs. Honestly, I can vision how that conversation goes:-
[manager]: Hi, so what is Emacs
[me]: Emacs is a text editor I use daily and makes me efficient in my work
[manager]: OK. I would like us to start using Visual Studio Code with the new projects coming up
[me]: Why? The consumption models we are using has no VSCode support, anyway.
[manager]: It would just be good if we are all using the same tools
[me]: It should not matter what we use as long as we work with git and deployment. If someone else is great with a different text editor why force them to use something else?
[manager]: (Looks up emacs)
[manager]: I think its best we stopped using it because it is not supported by Microsoft and we need to be careful with the dangers of open source.
[me]: OK. Should we contact other IT departments to replace any open source tools they use?
[manager]: Its just emacs is not verified software for the business. I think you are complicating things a little (tries to belittle me)
[me]: Emacs is my daily driver! If it goes, I will hand in my resignation!
* Manager is not there to understand or reason.. he is just following orders from other IT departments. *
Why is that a valid point?
For example, if I'm teaching a new hire to set up their vscode it is not very helpful to tell them "now you need to activate the python venv". It is much more helpful to be able to tell them "Now we're going to activate the python venv. To do that, open your command palette and search for 'select python interpreter'".
In my personal life, I still exclusively use emacs (which I have scripted to auto-detect venvs) but I put up with using vscode at work to be a greater utility to my team.
The point of the parent is that in an ideal situation, where everything works without flaw, theoretically it makes no difference which tools everyone uses. In real life, you having a homogeneous setup across a team makes the sysadmin's job a lot easier.
No. That's only a valid point if something about the tool must be shared between users, rather than just the output. Emacs is a text editor. It reads, modifies, and produces text. The correct tool for each team member to use is the one they're most productive with, full stop.
Jesus fucking Shiva while Odin watches, but I hate corporate management "thinking". It's just become more and more brain-dead over the decades.
Because the instruction was stupid, based on marketing instead of utility, or otherwise given without any thought to how it impacts the actual day-to-day work of their subordinates.
Why WOULDN'T you disobey a stupid instruction? What's the difference between "stop using this tool you're productive in and switch to this one that you're demonstrably LESS productive in for no reason other than I heard it was a good idea", and "Go strap some rocks onto your ankles and swim the English channel. I heard that was a good idea."?
You could add lisp to mspaint and mspaint suddenly becomes awesome somehow? I don't follow the logic
For general automation, my blog is built with Emacs Lisp.
Emacs is a 42-year-old software program that has been in constant development this entire time. Its git repository has over 180,000 commits right now on its main branch, which is still 20,000 ahead of VSCode. It doesn't just have a Lisp editor attached, it has 1.6 million lines of Lisp in it as well, and that's just the source repo, not all of the extensions you can get for it. Using "cloc" to count the total lines of source it has, it's still pretty close to 2/3rds the lines of code than VSCode has.
Yes, it gives you a lot of capabilities you didn't have before. The joke about it being a decent OS that needs a good text editor comes from the fact it has a large number of things it can do out of the box that aren't just text editing. It isn't just Notepad with a Lisp interpreter attached. It has vast capabilities that have been implemented and then also tested over the course of decades. Considering the set of disadvantages it carries with it, like weird key bindings and the fact that the variant of lisp it uses is more-or-less unique to emacs, somewhat analogously to the handicap principle [1] one should counterintuitively understand that as a sign that it must have extraordinary strengths that are able to offset that.
(I've used it for a long time, but I never really learned Lisp. AIs are making it much easier to customize than ever, though. I've said many times here on HN that I think every line of AI code should be reviewed. So yesterday I prompted Claude to build some Lisp functions so I can declare 1. a base directory 2. a regex of file names to match and produce 3. a function to walk over the entire directory forwards or backwards with CTRL-x CTRL-n or CTRL-x CTRL-p, thus allowing me to easily walk through an entire project for review purposes systematically. Nobody had to give me permission to do that. I didn't need to "create an extension". I don't have to care if anyone else in the world wants it. It's not the only editor that can do this as easily as emacs but it's a short list.)
[1]: https://en.wikipedia.org/wiki/Handicap_principle
This arguable. I personally use emacs for text editing for sure, but not only: it also does emails (notmuch), git (magit), team & project management (org), mastodon, fleet management (nix + colmena + custom elisp functions), and, more importantly, all these “applications” can mutually share data.
So can you use emacs as a text editor only? Sure. Can you leverage its intrinsic abilities to reach what might be called an automation harness? Yes as well.
A simple example: I wrote a function that let me highlight an X.509 cert in a YAML document, regardless of indentation, and pass it to 'openssl x509' to show me what it is. This has saved me lots of time over the years not having to copy/paste, fiddle with whitespace, etc. But it's only valuable because the functionality is now right at my fingertips in the environment I'm already in!
It's more correctly a Lisp execution environment with a text editor added as a bonus ;)
TBH that does sound pretty awesome, assuming good primitive operations were exposed through the Lisp API.
`M-x docter` is something I never had before.
With Unix, most programs are binary and while the shell is a good glue language, you can’t alter a program and the OS that much. With Emacs, only the core coded in C is sacred, anything else can be modified to fit your workflow. And there’s a lot of packages out there to provide you with raw materials.
Suggestions welcome.
I'm going to go through https://github.com/emacs-tw/awesome-emacs as well as https://www.masteringemacs.org/
https://www.youtube.com/watch?v=mJZDmO5yOxE
Where Emacs comes with all bells and whistles included in one big distribution, much like an operating system.
Norton Commander contains a text editor. Emacs operates at that level, whilst being reprogrammable.