> 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.
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.
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.
I'm unsure why you point this out. It's also a non issue if you're trying to drive a unicycle. Isn't it more interesting to talk about the cases where it applies? Or do you reckon all programs should be microservices?
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.
that seems backwards to me. one of the primary constraints in language development is the OS api. programs that don't interact with the world are increasingly less interesting, and you really have to work hard and be clever to change the file and its semantics, the socket, or the thread. these things have sharp edges and tend to be leaky.
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.
I certainly see that the OS interface is limit to language innovation in that it assumes a lot the things I mentioned, and these tend to get shoehorned in and turn into a series layer violations to poke through all the needed flags and controls.
we definitely gain a lot of acceleration from having a common substrate, but it acts a constraint.
virtual machines are really a good out, whether that's a hardware isolation layer, or just a software abstraction. I think the view that the hypervisors present (simple virtio style devices) are maybe a better canonical OS interface than the sprawling syscall+library model.
but sure, unless I wanted to develop a language and runtime that _really_ looked different, I would try to paper over posix to the degree possible.
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).
Unix philosophy clearly favors and privileges certain methods of composition and interoperation. C-calls, program invocation, files and sockets/pipes. Calls inside various vms like lisp, java, python or wasm are not among those.
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 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?"
Start sending out your resume and reaching out to your network about other jobs.
Any company that anally controls every last software developers can install is a dead man walking. At least the software development part of the company.
Getting up to speed on new tools and new technologies is essential to the job of software development. Projects will grind to a halt and fail to deliver, but the management will never understand the InTune lockdown is the cause.
Thank you for your message. I appreciate you going out of your way and showing care for others - in this case my career.
I have updated my resume and looking.
I have a couple of years left in order to look after (what I now call) our legacy software, which we wrote, until we move over 100% with the new tools. It is dead end as a software engineer and don't intend to fall behind.
The company I work for is pretty much washing its hands and going with off-the-shelf solutions, instead.
We are transitioning into a role that's mostly extending a main business software internally and externally. Externally it is using Logic Apps or Power Automate or Power Apps, etc.
With this, the "core" tools we are using are no longer needed in the minds of upper management, which is why I am concerned changing laptops that are fully setup with Intune.
This is also why in my meetings with management they are subtly suggesting software well before we move onto these modern projects - as if I wont understand what they doing.
technically we are still developers but not the way we were originally hired, and I am confused how we are going to hire new staff in this area... and the type of skills we require.
With all the above, I can see them being difficult with Emacs and other software I use.
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.
Back in the day when i had a windows laptop for work you could just download the windows binary distribution of emacs and run that, has something changed?
This is what I do when I use Windows.
However, in recent years, I tend to use Emacs via WSL.
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.
Does Intune stop you from running any unapproved .exe's? Because IIRC Emacs can run as a "portable" executable that doesn't need to be installed in Program Files.
(I don't have any experience with Intune so pardon my ignorance.)
Depending on the job, you can likely be fired without cause anyway. You can pretend to not poke the bear, but in a place that plays power games like that, it doesn't really matter.
Presumably performance matters above all else (although it likely doesn't in such a place). If Emacs actually makes a meaningful difference, then just use it to do your work more efficiently.
You can run a batch/shell script, right? Of course you can. Would you ask for permission to write and run a script? If not (and presumably you wouldn't because that would be silly) then you shouldn't ask to run Emacs. You "own" both and take on all the "risk". There's really no difference.
But really, truly ask yourself, is whatever cause you're working towards (that is, the mission of the company) worth sacrificing your dignity for?
OMG. Don't let me even start here. Corporate IT cultures sometimes are so exhaustingly cretinous. With straight faces they'd perform "security theatre" that has nothing to do with security, but is still just so infuriatingly time-consuming and ignorant on even most basic things. Honestly, I am so thankful to Emacs for cultivating a hacker's mindset in me, otherwise I'd be so freaking burned out all the time if I didn't know how to bypass most of the nonsense they enforce on everyone. I even asked my IT guy once: "I don't get it, don't they realize that devs are just gonna play along with this bullshit maybe a couple of times and then they'll just fucking script a workaround? I for sure will...", and he was like: "I know, it is so stupid, but hey, I don't make these decisions here..."
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.
Unironically. I once was told by my manager, that I got to fix being an introvert.
I stayed for 8 months in that company (would be less, but such is the expat's life on a visa), and leaving was the best professional decision of my life.
> 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 :-)
Emacs users (myself included) would feel less like cramming every aspect of our work into Emacs if more tools embodied the freedom and hackability that comes with using Emacs. It's not that Emacs is better, it's that other tools are more restrictive and not self-documenting.
It's also helpful that you get a certain degree of UI consistency from things like completing-read being used everywhere. And even when some package departs from convention, everything is still a buffer, so anything in it is easy to reuse.
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.
Idunno. I think you end up teaching them nothing and just doing it for them. I mentor plenty folks without learning more than basics of vscode/cursor, and the most important lesson for them is always how to figure out how to do stuff (which has never been easier than today).
Yeah, I kinda feel like when you're mentoring people, you should let them drive. If you're going to do it for them, you might as well just record a training video.
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.
But sysadmins should be there to deploy stuff and make sure the infra does its job, not get bogged down handholding some dev that can't even compile a project.
I've worked at more than one place where administration and sys admins were the ones calling the shots. Certainly not the people actually producing stuff.
When I've been in that position, I've just trusted junior folks to figure out the tooling-specific way to do things like that, and it's worked out perfectly well. If anything, it leaves people happier and learning more.
And, instead, I can focus on the fuzzier, higher-level things that involve non-trivial tacit knowledge rather than things somebody can resolve with a Google search (or just ask Claude).
The only truth is running the tools from the shell. Plugins are great conveniences and productivity enhancers. But if your devs can’t use the command line to build your software, you need to stop everything and teach them that.
Now if you want to have a standard tool set that you provide documentation for and support, then if anyone uses a different tool they are on their own. That’s perfectly fine.
But if you don’t trust your developers enough to choose their own tools, how can you trust them to deliver important software for your company?
I can somewhat sympathize - I guess the debatable aspect is to what extent should you teach?
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.
It's just less effort all round to have everybody using the same supported set of tools. I don't know if I've ever worked on a project that's gone so far as to actually mandate this, but a "should" (possibly in the RFC sense) is fair enough I think. Every project I've worked on has ended up with everybody eventually settling on using the same tools, because it's just overall less hassle that way.
(Regarding Emacs, I'm typically using it anyway for org-mode, so if I need to do some one-off edit or other - probably some keyboard macro thing - then I can just load the problem file into Emacs and save it back out again afterwards. I've only once been in the situation of neither being allowed to install it nor remotely connect to another machine to use it.)
> 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.
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?
> 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.
> 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."?
Depends what country you're in. In the US we have a culture in engineering of doing what we believe is right regardless of what the manager wants. We can afford to do that because of how highly specialized our work is and how few engineers there are (this is probably changing with AI). But in other countries managers are looking for any excuse to replace you with someone who will just nod their head and do whatever they ask.
In my youth, I openly railed against this type of thinking. I was near quitting one gig when the VP said that all work done on our Dec 10 had to be done in batch mode. Fortunately, this dictum was shortly reveresed.
To further answer why I would disobey a direct instruction is that I presume those hiring me expect me to produce solutions to problems--have a problem solving attitude. A direct instruction of that sort is contrary to that.
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
> Don't forget this is a text editor, not an IDE or some general purpose automation harness
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.
> 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!
Emacs is not an editor. It's a Lisp-powered text orchestrator. It allows you to read, write, ocr, encrypt, decrypt, compile, debug, profile, browse, rss, email, calendar, track, journal, publish, tangle, run, query, spawn, multiplex, ssh, edit, diff, merge, blame, rebase, stage, review, chat, note, link, roll, play, run, preview, transcode, transcript, evaluate, redefine, introspect and rebuild anything in your computational vicinity - local and remote machines.
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?
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.)
Fortunately all the "weird key bindings" can be easily changed.
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.
There is a decent solution for this, you essentially define your own minor mode with key bindings you want to take precedence. I haven’t tried it myself yet, but seems useful in theory https://youtu.be/D99GB591Vgo
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 send text messages from Emacs because my phone doesn't get service in my basement. Sure I could do the same thing with any programming language, but it took me like 2 hours to hack something together on top of Emacs' built in IRC client.
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".
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.
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 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 computer go via system calls.
Norton Commander contains a text editor. Emacs operates at that level, whilst being reprogrammable.
Most people aren't using vim that way. For your example, tmux would be more like emacs in the sense that you live in it, manages your windows, etc. Vim is just another tool in some window along with others.
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.
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.
In retrospect, the name `emacsclient` was a poor one because in 2026 most folks new to Emacs expect it to act like a REST client, where runtime state is synchronized between the client and server over a network. Emacs' usage of ‘client’ and ‘server’ here refer to the usage of a Unix local domain (i.e. file system) socket for simple control commands from the socket client. This was later extended to support a network socket, but the client still only sends simple control commands.
`ssh -X` has awful performance for some reason. You can see each line render individually when invoking the Info manual on Emacs even while within LAN.
It's better if you enable TCP connections on your X11 server, setup a Wireguard VPN between your Emacs host and your X11 server host, and a firewall to only permit X11 connections over that. Throughput and latency then should be so good the remote Emacs window/frame will be indistinguishable from local ones (at least within LAN, haven't really tried over the internet).
> Do beware though that if you use the non-PGTK GTK build, closing this new frame will crash the remote Emacs.
Guess I've used the good one. Haven't had this problem. What I do have is that if you open a frame in a host that you then put to sleep long enough for the X11 connection to timeout on the Emacs host, then `emacs --daemon` will crash. When I've used it, I've just made sure to save buffers often. systemd would start `emacs --daemon` again on its own.
`emacs --daemon` has no problem using multiple simultaneous X11 connections to different hosts, but it just doesn't handle the connections closing on their own. It also doesn't itself close X11 connections when all frames to an X11 server have been closed. So even if you close all of a machine's Emacs frames prior to putting it to sleep, it still causes `emacs --daemon` to crash.
It's been a number of years, and all I really remember is coming to the conclusion that "emacsclient only works with a local server." It uses a domain socket for this, but forwarding that from a remote server doesn't seem to be enough.
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.
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
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.
> 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.
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.
"An operating system is a collection of things that don't fit into a language. There shouldn't be one"
-- Dan Ingalls
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.
That is mostly a non issue on microservices and serverless runtimes running on top of type 1 hypervisors, and bare metal embedded deployments.
I'm unsure why you point this out. It's also a non issue if you're trying to drive a unicycle. Isn't it more interesting to talk about the cases where it applies? Or do you reckon all programs should be microservices?
Developers love building on platforms. Saying there shouldn't be platforms defies reality.
Edit: Looking up the quote it seems to just be the person being pedantic in how they define operating systems.
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.
that seems backwards to me. one of the primary constraints in language development is the OS api. programs that don't interact with the world are increasingly less interesting, and you really have to work hard and be clever to change the file and its semantics, the socket, or the thread. these things have sharp edges and tend to be leaky.
> that seems backwards to me
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.
I certainly see that the OS interface is limit to language innovation in that it assumes a lot the things I mentioned, and these tend to get shoehorned in and turn into a series layer violations to poke through all the needed flags and controls.
we definitely gain a lot of acceleration from having a common substrate, but it acts a constraint.
virtual machines are really a good out, whether that's a hardware isolation layer, or just a software abstraction. I think the view that the hypervisors present (simple virtio style devices) are maybe a better canonical OS interface than the sprawling syscall+library model.
but sure, unless I wanted to develop a language and runtime that _really_ looked different, I would try to paper over posix to the degree possible.
> Edit: Looking up the quote it seems to just be the person being pedantic in how they define operating systems.
What a surprise
Pragmatism beats idealism in the real world
In the Linux world, isn't the c compiler necessary for Linux to function?
To build? Sure.
To run? Absolutely not.
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).
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.
Bash is a shell refugee in Unixland. It doesn't follow the Unix philosophy, it follows the Shell philosophy. But it integrates.
Why do you say such silly things?
Unix philosophy clearly favors and privileges certain methods of composition and interoperation. C-calls, program invocation, files and sockets/pipes. Calls inside various vms like lisp, java, python or wasm are not among those.
> 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.
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 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?"
I was a bit surprised when about ten years ago I noticed that there were now really only two reactions to my Emacs use:
"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!"
Start sending out your resume and reaching out to your network about other jobs.
Any company that anally controls every last software developers can install is a dead man walking. At least the software development part of the company.
Getting up to speed on new tools and new technologies is essential to the job of software development. Projects will grind to a halt and fail to deliver, but the management will never understand the InTune lockdown is the cause.
Hi jimbokun
Thank you for your message. I appreciate you going out of your way and showing care for others - in this case my career.
I have updated my resume and looking.
I have a couple of years left in order to look after (what I now call) our legacy software, which we wrote, until we move over 100% with the new tools. It is dead end as a software engineer and don't intend to fall behind.
Over the past 15 years, I worked for 4 different companies in 4 different industries and I never had any trouble getting Emacs approved.
They were all rather smallish, always around 200 employees, though.
The company I work for is pretty much washing its hands and going with off-the-shelf solutions, instead.
We are transitioning into a role that's mostly extending a main business software internally and externally. Externally it is using Logic Apps or Power Automate or Power Apps, etc.
With this, the "core" tools we are using are no longer needed in the minds of upper management, which is why I am concerned changing laptops that are fully setup with Intune.
This is also why in my meetings with management they are subtly suggesting software well before we move onto these modern projects - as if I wont understand what they doing.
technically we are still developers but not the way we were originally hired, and I am confused how we are going to hire new staff in this area... and the type of skills we require.
With all the above, I can see them being difficult with Emacs and other software I use.
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.
Back in the day when i had a windows laptop for work you could just download the windows binary distribution of emacs and run that, has something changed?
This is what I do when I use Windows. However, in recent years, I tend to use Emacs via WSL.
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.
Does Intune stop you from running any unapproved .exe's? Because IIRC Emacs can run as a "portable" executable that doesn't need to be installed in Program Files.
(I don't have any experience with Intune so pardon my ignorance.)
Yes, running software that is not authorized can get you fired.
Depending on the job, you can likely be fired without cause anyway. You can pretend to not poke the bear, but in a place that plays power games like that, it doesn't really matter.
Presumably performance matters above all else (although it likely doesn't in such a place). If Emacs actually makes a meaningful difference, then just use it to do your work more efficiently.
You can run a batch/shell script, right? Of course you can. Would you ask for permission to write and run a script? If not (and presumably you wouldn't because that would be silly) then you shouldn't ask to run Emacs. You "own" both and take on all the "risk". There's really no difference.
But really, truly ask yourself, is whatever cause you're working towards (that is, the mission of the company) worth sacrificing your dignity for?
Any company that locks down the software developers can install is dead already.
> they are doing various changes (and control)
OMG. Don't let me even start here. Corporate IT cultures sometimes are so exhaustingly cretinous. With straight faces they'd perform "security theatre" that has nothing to do with security, but is still just so infuriatingly time-consuming and ignorant on even most basic things. Honestly, I am so thankful to Emacs for cultivating a hacker's mindset in me, otherwise I'd be so freaking burned out all the time if I didn't know how to bypass most of the nonsense they enforce on everyone. I even asked my IT guy once: "I don't get it, don't they realize that devs are just gonna play along with this bullshit maybe a couple of times and then they'll just fucking script a workaround? I for sure will...", and he was like: "I know, it is so stupid, but hey, I don't make these decisions here..."
[dead]
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.
Unironically. I once was told by my manager, that I got to fix being an introvert.
I stayed for 8 months in that company (would be less, but such is the expat's life on a visa), and leaving was the best professional decision of my life.
> 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 :-)
Emacs users (myself included) would feel less like cramming every aspect of our work into Emacs if more tools embodied the freedom and hackability that comes with using Emacs. It's not that Emacs is better, it's that other tools are more restrictive and not self-documenting.
It's also helpful that you get a certain degree of UI consistency from things like completing-read being used everywhere. And even when some package departs from convention, everything is still a buffer, so anything in it is easy to reuse.
That, and also the fact that everything is well-integrated and interoperable, allowing a more seamless interaction between the different tools.
> Their argument is that all team members should use the same tools, and I guess that is a valid point.
Why is that a valid point?
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.
Idunno. I think you end up teaching them nothing and just doing it for them. I mentor plenty folks without learning more than basics of vscode/cursor, and the most important lesson for them is always how to figure out how to do stuff (which has never been easier than today).
Yeah, I kinda feel like when you're mentoring people, you should let them drive. If you're going to do it for them, you might as well just record a training video.
At some point, shouldn't installing a venv be a pre-requisite to actually be hired as a dev?
That was just an example.
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.
But sysadmins should be there to deploy stuff and make sure the infra does its job, not get bogged down handholding some dev that can't even compile a project.
I've worked at more than one place where administration and sys admins were the ones calling the shots. Certainly not the people actually producing stuff.
When I've been in that position, I've just trusted junior folks to figure out the tooling-specific way to do things like that, and it's worked out perfectly well. If anything, it leaves people happier and learning more.
And, instead, I can focus on the fuzzier, higher-level things that involve non-trivial tacit knowledge rather than things somebody can resolve with a Google search (or just ask Claude).
That’s very dangerous,
The only truth is running the tools from the shell. Plugins are great conveniences and productivity enhancers. But if your devs can’t use the command line to build your software, you need to stop everything and teach them that.
Now if you want to have a standard tool set that you provide documentation for and support, then if anyone uses a different tool they are on their own. That’s perfectly fine.
But if you don’t trust your developers enough to choose their own tools, how can you trust them to deliver important software for your company?
I can somewhat sympathize - I guess the debatable aspect is to what extent should you teach?
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.
[1] https://github.com/casey/just
That sounds lovely and a much more adult work environment than locking down everyone’s laptop.
It's just less effort all round to have everybody using the same supported set of tools. I don't know if I've ever worked on a project that's gone so far as to actually mandate this, but a "should" (possibly in the RFC sense) is fair enough I think. Every project I've worked on has ended up with everybody eventually settling on using the same tools, because it's just overall less hassle that way.
(Regarding Emacs, I'm typically using it anyway for org-mode, so if I need to do some one-off edit or other - probably some keyboard macro thing - then I can just load the problem file into Emacs and save it back out again afterwards. I've only once been in the situation of neither being allowed to install it nor remotely connect to another machine to use it.)
What about the job is so good as to make you tolerate this?
Taken a look at the job market lately? Unless you’re like the top 1% (which most people aren’t), it’s extremely bleak.
Plus, I'm not very hirable to begin with, having wasted most of my professional life in academia.
> 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.
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?
> 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.
You could set the building on fire.
... how would they tell?
By looking at my screen? But also, why would you disobey a direct instruction from you super?
> 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."?
[dead]
Depends what country you're in. In the US we have a culture in engineering of doing what we believe is right regardless of what the manager wants. We can afford to do that because of how highly specialized our work is and how few engineers there are (this is probably changing with AI). But in other countries managers are looking for any excuse to replace you with someone who will just nod their head and do whatever they ask.
> But also, why would you disobey a direct instruction from you super?
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.
In my youth, I openly railed against this type of thinking. I was near quitting one gig when the VP said that all work done on our Dec 10 had to be done in batch mode. Fortunately, this dictum was shortly reveresed.
To further answer why I would disobey a direct instruction is that I presume those hiring me expect me to produce solutions to problems--have a problem solving attitude. A direct instruction of that sort is contrary to that.
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
> Don't forget this is a text editor, not an IDE or some general purpose automation harness
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.
> 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!
Emacs is not an editor. It's a Lisp-powered text orchestrator. It allows you to read, write, ocr, encrypt, decrypt, compile, debug, profile, browse, rss, email, calendar, track, journal, publish, tangle, run, query, spawn, multiplex, ssh, edit, diff, merge, blame, rebase, stage, review, chat, note, link, roll, play, run, preview, transcode, transcript, evaluate, redefine, introspect and rebuild anything in your computational vicinity - local and remote machines.
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?
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.)
[1]: https://en.wikipedia.org/wiki/Handicap_principle
Fortunately all the "weird key bindings" can be easily changed.
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.
There is a decent solution for this, you essentially define your own minor mode with key bindings you want to take precedence. I haven’t tried it myself yet, but seems useful in theory https://youtu.be/D99GB591Vgo
> Don't forget this is a text editor, not an IDE or some general purpose automation harness
It's more correctly a Lisp execution environment with a text editor added as a bonus ;)
A lisp interpreter with text editing primitives.
And dynamic buffer local scoping.
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.
> Don't forget this [emacs] is a text editor, not an IDE or some general purpose automation harness
How familiar are you with Emacs?
>Don't forget this is a text editor, not an IDE or some general purpose automation harness
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)
Emacs is, in fact, an IDE and some general purpose automation harness. And some other stuff.
That's the point.
> You could add lisp to mspaint and mspaint suddenly becomes awesome somehow?
TBH that does sound pretty awesome, assuming good primitive operations were exposed through the Lisp API.
It would become AutoCAD. That is pretty awesome.
the analogy is you have mspaint (or blender)
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
> You could add lisp to mspaint and mspaint suddenly becomes awesome somehow? I don't follow the logic
Yes exactly! https://docs.gimp.org/3.2/en/gimp-using-script-fu-tutorial.h...
I send text messages from Emacs because my phone doesn't get service in my basement. Sure I could do the same thing with any programming language, but it took me like 2 hours to hack something together on top of Emacs' built in IRC client.
> Did Emacs really give YOU any capability you didn't have before?
`M-x docter` is something I never had before.
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.
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.
Suggestions welcome.
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".
Nice.
I'm going to go through https://github.com/emacs-tw/awesome-emacs as well as https://www.masteringemacs.org/
Assuming you're on GNU/Linux:
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.
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.
It's a shell not an operating system but the concept of a shell isn't commonly understood.
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 computer go via system calls.
Norton Commander contains a text editor. Emacs operates at that level, whilst being reprogrammable.
Most people aren't using vim that way. For your example, tmux would be more like emacs in the sense that you live in it, manages your windows, etc. Vim is just another tool in some window along with others.
Came across this recently, which I find is a good and short intro to Emacs for people who don't use it:
https://www.youtube.com/watch?v=mJZDmO5yOxE
Now I am really curious to see Anon Emoose's init.el
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.
Emacs itself can run as a client and server. To start the server:
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.
In retrospect, the name `emacsclient` was a poor one because in 2026 most folks new to Emacs expect it to act like a REST client, where runtime state is synchronized between the client and server over a network. Emacs' usage of ‘client’ and ‘server’ here refer to the usage of a Unix local domain (i.e. file system) socket for simple control commands from the socket client. This was later extended to support a network socket, but the client still only sends simple control commands.
> Emacs' usage of ‘client’ and ‘server’ here refer to [...] simple control commands
Despite that, it still enables this:
> where runtime state is synchronized between the client and server over a network
On graphical X11 frames:
https://news.ycombinator.com/item?id=48864196
but it also enables having multiple TUI `emacsclient -c -nw` frames over SSH.
Forwarding the socket doesn't work, but if you use X11 then you can use `ssh -X`, and the remote Emacs will open a frame on your local X server.
Do beware though that if you use the non-PGTK GTK build, closing this new frame will crash the remote Emacs.
`ssh -X` has awful performance for some reason. You can see each line render individually when invoking the Info manual on Emacs even while within LAN.
It's better if you enable TCP connections on your X11 server, setup a Wireguard VPN between your Emacs host and your X11 server host, and a firewall to only permit X11 connections over that. Throughput and latency then should be so good the remote Emacs window/frame will be indistinguishable from local ones (at least within LAN, haven't really tried over the internet).
> Do beware though that if you use the non-PGTK GTK build, closing this new frame will crash the remote Emacs.
Guess I've used the good one. Haven't had this problem. What I do have is that if you open a frame in a host that you then put to sleep long enough for the X11 connection to timeout on the Emacs host, then `emacs --daemon` will crash. When I've used it, I've just made sure to save buffers often. systemd would start `emacs --daemon` again on its own.
`emacs --daemon` has no problem using multiple simultaneous X11 connections to different hosts, but it just doesn't handle the connections closing on their own. It also doesn't itself close X11 connections when all frames to an X11 server have been closed. So even if you close all of a machine's Emacs frames prior to putting it to sleep, it still causes `emacs --daemon` to crash.
could you see the reason it didn't work?
It's been a number of years, and all I really remember is coming to the conclusion that "emacsclient only works with a local server." It uses a domain socket for this, but forwarding that from a remote server doesn't seem to be enough.
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.
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
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.
OP here. This post resonated far more than expected. Thanks all for the feedback!
[dead]
[dead]
[dead]