Emacs standing alone on a Linux Kernel

That's right.

What them made Lisp Machines was a mix of things:

* the command interface is based on the Lisp REPL (read eval print loop)

* the operating system itself is written in Lisp

* the instruction set of the CPU is optimized for Lisp (for example via microcode)

* the CPU itself might have hardware support for Lisp (for example for efficient GC)

* the hardware itself (console, keyboard, system bus, extension cards, memory, ...) is used directly from Lisp and might be optimized for it (like special keyboards, special memory cards, special fronted computers, ...)

What's OTOH rarely is the case, that they run Lisp directly in Hardware -> which would mean that the CPU itself is a Lisp interpreter.

> Maybe we're all just getting old, and the dream of "one text editor for everything" is becoming one of those quaint old notions of yesteryear.

I mean, that's only ever been a dream in the emacs community. Vim might have toy plugins for other stuff, but by and large people use it to edit period. As it should be, isn't the whole UNIX philosophy to do one thing well? If I want email or a text browser in the CLI (I don't) I'll use dedicated, better, faster programs, each on a tmux pane that I can use instantly with a keyboard shortcut, rather than wait for a slow emacs buffer to load.

The problem is one of context. When editing a programming language buffer, the editor needs to be aware of the entire buffer, because a { on the first line could match to a } on the 1235987th line and affect hilighting as well as editing commands like indentation, or sexp navigation. Meanwhile, ideally, in a log buffer the only information needed to nicely render a single line is contained on that line. Or perhaps the log unit is multiline, but still somehow boundable. In that case the editor should be able to do presentation in constant time based on the segment of the buffer that's visible.

Unfortunately, what with logging in JSON and so on, these two cases aren't really distinct anymore. But if I did want to use one editor for both log viewing and coding, I'd pick the one that was the most easily and interactively customizable.

I use the latest versions with native compilation and gave up on terminals and curses codes in favor of plain M-x shells. I tend to accumulate hundreds of buffers, some of them GB size, and all is super snappy. I am very sensitive to latency and can’t stand slow pings, avoid wireless for that reason, and have tuned my keyboards over the years to reduce input latency and errors. Emacs out of the box is super fast. The plain text input loop is in microseconds so not perceptible. And there is hardly ever a need for terminal emulators but when there absolutely is (say htop) then you can use vterm.

> And I wanted to like Emacs for that. But it's just really slow, and the moment you have a number of buffers with lots of content it's hardly usable.

Do you mean vanilla emacs or a bespoke configuration?

Number of buffers should not slow emacs down and never has across many versions and platforms for me on vanilla emacs.

I would find it hard to believe vanilla emacs was slow switching between lots of buffers. Perhaps if you had 6 windows (as emacs refers to panes) evenly split of minified javascript on a single line it would be slow?

However an issue in my bespoke configurations that has caused the buffer switching issue you mention before is adding a call to the modeline and not debouncing.

The commands before that step are used to build the Linux system.

As in software engineering, the art is to build a solution that can be easily taken apart for spare parts when it becomes time to change or refactor it.