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"
-- 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.
I'm not sure I completely understand which part you find backwards. Do you mean merging language runtimes and the OS is a bad idea, or that you think merging them would lead to more innovation?
I can see an argument for both (in terms of innovation), but being able to run only one language environment on a computer at a given time would make it much harder and heavy weight to use new languages. Or at the very least, new language runtimes.
What a surprise
Pragmatism beats idealism in the real world
In fairness that used to be common to have in most IDEs.
I don’t know if it’s still the case but i remember that the first java language server was spun off the Eclipse’s java semantic parsing engine.
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. *
"Emacs? What's that? Oh, sorry, I like things with an actual UI."
Or:
"Emacs? I remember that from my DEC days. I'm surprised it's still around!"
However, I believe Microsoft Intune is used within the Business to control what software can and cannot be installed. So my guess is Windows won't allow you to install via a typical .exe
I am not suggesting the above is 100% valid. I just don't want to get a new laptop and find out. Maybe I can still use Emacs via WSL... bypassing Intune????
At the end of the day, I understand Security is getting much more serious in recent years - and we even have a dedicated department - but controlling the software to install is crazy, especially for a development team.
(I don't have any experience with Intune so pardon my ignorance.)
Not really. If they mandated all team members use telnet instead of ssh, would you say their position is valid?
Anyway, the important thing to learn is "You're not supposed to ask if you can use Emacs. Just use it!"
Incidentally, do they have a mandated general text editor? And if they do, will you get in trouble for firing up Notepad?
Do they have a mandated TODO tool (for your own tracking of work, not something like Jira meant for the whole group)? I've yet encountered a place that did.
Basically, find some category that Emacs does that they've not mandated, and then install Emacs and tell people you're using it for that category :-)
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.
If someone knows no development tools, then yes, it is good if someone in the team knows Visual Studio Code and can guide them. In my previous job, another senior person knew it and helped out (VSCode was not mandated, and they were free to use some other tool).
I tend to focus on training people on the concepts (code navigation, debugging, version control, etc), and tell them that they're free to use whatever tool they like, but it's on them to learn how to use those tools to apply those concepts. I usually recommend VSCode and tell them there are plenty of videos/sites that explain them.
Then if I see them doing something very inefficiently, I do a quick Google search to see if the more efficient approach is supported in their tool and send them a link.
It's important to hire people who can learn on their own (with guidance on what to learn).
> 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'".
Inspired by a submission some years ago on HN, I came up with a different approach in my last job.
Everything the team did (including onboarding), had to be done via a just[1] recipe. No longer did we rely on outdated docs. just recipes, by definition, cannot be outdated because then we wouldn't be able to do our work.
For onboarding, we had recipes that automated as much of the configuration as possible. For things that required manual work, the recipe would print instructions, and prompt the user to press Enter when they had completed the task.
Sure, onboarding stuff can go stale as people don't onboard often, but we had a policy that if any senior team member had to help a newbie because the recipe was broken, then the senior member needed to fix the recipe and check it in.
I left the job, but I still talk to some of the folks there. They still love the recipes.
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 they disobey their superior (and if they don't, recurse).
But yeah, if I were new to the job, I would wait until I'm fairly competent before playing those games.
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."?
I don’t consider telling a manager that something is not a reasonable ask to be an act of disobedience.
There is too much power distance between yourself and your manager.
Why?! It is a text editor for crying out loud. If you are more productive using the tools you want, don't cost anything to the company and doesn't force your colleagues to adopt your workflow, you could be working with notepad for all I care.
You could add lisp to mspaint and mspaint suddenly becomes awesome somehow? I don't follow the logic
Technically, it is just a text editor. It was created to be a text editor, so you are right, but up to a point.
Emacs is written in lisp, what it means? It means that the only part of emacs written in C is a lisp machine. And even not the whole lisp machine is written in C: there is a rudimentary read-eval-print loop (REPL), and maybe a bytecode interpreted. This REPL I believe is just to boot up purposes and is replaced with proper lisp implementation on later boot up stages. It is not lisp added to a text editor, it is a text editor added to lisp. It means, in particular, you can add to that lisp not just text editor but anything else too, like mspaint for example.
And people do just that. They write software in emacs. In particular they wrote IDE in emacs, so while emacs by itself is not an IDE, you can turn it into one.
> some general purpose automation harness
Oh, it is. It is more general than any other automation harness you know. It is a lisp machine, you can automate anything in it. Well, technically you can, in practice it can take take too much time to be practical. In practice when choosing automation harness, you'd prefer not the most general, but the most specific harness for your task.
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 ;)
you add MCP (or an API)
suddenly with llama.cpp and a small model like qwen 3.6 35B, you can automate things by just asking.
emacs same thing, you can 'script' everything. Except no LLM needed
For general automation, my blog is built with Emacs Lisp.
Admittedly, it doesn't help that there are some sibling comments that implicitly seem to be speaking that way.
However, 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, at 2,613,748 for emacs versus 3,849,521 for VSCode. So that's the scale we're talking here, something on par with an IDE, not something on par with a simple text editor.
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.)
The only difficulty is caused by the fact that already each Emacs mode may change some of the key bindings. Because of that, before deciding on some key bindings you prefer, it is wise to first check the bindings used in all the Emacs modes that you are likely to use frequently, in order to choose bindings that would not conflict with any of those modes.
How familiar are you with Emacs?
TBH that does sound pretty awesome, assuming good primitive operations were exposed through the Lisp API.
It's all 3 and way more.
>You could add lisp to mspaint and mspaint suddenly becomes awesome somehow? I don't follow the logic
That much is a given (for both)
`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/
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.
emacs --daemon
Unfortunately it only works locally. I've tried to forward the emacs server socket over ssh to a remote client and it doesn't work.
Do beware though that if you use the non-PGTK GTK build, closing this new frame will crash the remote Emacs.
Simply editing a remote file over an ssh connection is easy enough using TRAMP, but that isn't the same as accessing existing buffers in a remote server.