"An operating system is a collection of things that don't fit into a language. There shouldn't be one"

-- Dan Ingalls

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?

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.

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.

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?

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

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.

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.

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.

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

Taken a look at the job market lately? Unless you’re like the top 1% (which most people aren’t), it’s extremely bleak.

By looking at my screen? But also, why would you disobey a direct instruction from you super?

> 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

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

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.

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

Assuming you're on GNU/Linux:

  (setq read-process-output-max
        (with-temp-buffer
          (insert-file-contents "/proc/sys/fs/pipe-max-size")
          (string-to-number (buffer-string))))

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.

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

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