29 comments

[ 6.5 ms ] story [ 215 ms ] thread
I have been using emacs for the past couple of years. Started because I wanted to try out org mode and stayed for the extreme flexibility it offers.
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
> 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.

"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

An OS is a virtual machine meant to be shared among programs. Sure the central examples expose most of an ISA that they run on themselves, but there are also examples like Inferno, Taos, AS/400.
> Only because Lisp Machines, or variations thereof didn't took off in the mainstream

It apparently turned out that it was more efficient to compile Lisp to a "normal" CPU instead of using an expensive custom non-generic "Lisp" CPU.

It's a shell not an operating system but the concept of a shell isn't commonly understood.
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
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).
> Heck, there's a whole semantic parsing engine buried within (CEDET), which nowadays is pretty much unused

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.

Emacs is a LISP refugee in Unixland. It doesn't follow the Unix philosophy, it follows the LISP philosophy. But it integrates.

Forgot where I found this.

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

> Their argument is that all team members should use the same tools, and I guess that is a valid point.

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.

Having everyone on a team have different personalities is managerially inefficient. You have to deal with each team member in a different way instead of being able to have a unified emotional approach. So we required frontal lobotomies for everyone on the team.
What about the job is so good as to make you tolerate this?
> Their argument is that all team members should use the same tools, and I guess that is a valid point.

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

What a nightmare. The day anyone tells me not to use a specific editor regardless of what it is, I'd be opening their suggested one to type my resignation letter. And not because I love Emacs, Vim or whatever.

I mean I'd understand enforcing using specific tools while pair-programming, mentoring, etc., but not allowing a software engineer to use whatever editor they are most comfortable using at all is not even dystopian, it's simply imbecilic. How are they supposed to not just "perform" but to get any shit done at all? It's equivalent of hiring a secretary and asking them to type everything in Hebrew (a language they have zero awareness of), using Dvorak (a layout they've never tried) and then complaining that their typing speed is undesirable.

How the fuck do these people even get to managerial positions? How in the world are these kinds of companies and company cultures not bankrupted themselves out of existence?

You could set the building on fire.
(comment deleted)
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.
Emacs itself can run as a client and server. To start the server:

  emacs --daemon
Then use `emacsclient` to connect to it. All `emacsclient` instances whether in terminals or GUI are using the same server and can access the same open files and buffers.

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.

OP here. This post resonated far more than expected. Thanks all for the feedback!
(comment deleted)
One thing that's easy to forget is how much of the "everything is a service" idea predates LSP. Emacs had long-running subprocesses, RPC-ish interactions, TRAMP, GUD, REPL integration, etc. LSP standardized one important interface, but it wasn't the beginning of the architecture.
Emacs is a Platform. Operating Systems are also Platforms. Many other things are platforms. A platform is a layer of software designed to enable you to build new things on it. This should raise the question: What platform X would be good for building this thing Y I want to build? I often find X = Emacs, but also Racket, Rust, et al. An application which is also a good platform may be worth a greater learning investment than a simpler application would justify.