Personally, I don't buy into this argument. I think having a globally shared buffer state, etc. is an antifeature. Plus, there's no reason that starting a TUI program should be that slow.

Either way, this only addresses startup time too. The rest of the issues: text insertion lag, `project-find-file` being slow in large repos, etc. all remain.

The slowness on startup in my emacs mainly comes from my customizations - over the last almost 3 decades I've accumulated roughly 30k loc of custom lisp, plus a lot of 3rd party stuff.

But I typically start emacs at boot, and then it runs until I reboot. I usually have one GUI frame, and one tui frame running in tmux so I can easily attach to my emacs session from a different computer. I have an emacsclient wrapper that opens stuff from the command line in my running emacs (and also mail wrappers, so clicking on a mail link in a browser opens a mail compositor in emacs).

I'm using eyebrowse with a bunch of own convenience features for workspaces in emacs - stuff like "when I switch to a buffer it'll switch to the workspace wher e that buffer is open unless I tell it I want it here". Combine that with some custom SSH entry points and especially on the notebook where I only have one screen it's way more comfortable to use than the OS window management for a terminal/ssh session messy like me.

> I think having a globally shared buffer state, etc. is an antifeature.

As someone who mostly lives in Emacs, I like it. If I'm away from a machine, I can SSH into it and carry on with whatever I was in the middle of.

It's also nice to set emacsclient as EDITOR, so that e.g. running `git commit` will open up a buffer in the existing Emacs session. This is especially useful since I use shell-mode, and it would be confusing/weird to have new Emacs instances popping up when I'm already in an editor! (They open in a "window" (i.e. pane) in the existing "frame" (i.e. window) instead)

> Plus, there's no reason that starting a TUI program should be that slow.

There's no reason why it shouldn't. You seem to think that the interface obliges a program into a certain performance pattern. No such obligation exists. And Emacs isn't a TUI program, it only happens to have a terminal interface among many others.

> having a globally shared buffer state, etc. is an anti-feature

Yeah, it feels a bit weird to not have some isolation.

Spacemacs offers layouts[^1] that give you some buffer-isolation. Each window has a "layout", and layouts have sets of buffers. It works well, but you can run into extra prompts if you open the same buffer from two layouts and try to kill it from one of them (kill the buffer (for all layouts)? just remove from this layout? In my mind the latter should just be the default).

[^1]: https://www.spacemacs.org/doc/DOCUMENTATION.html#layouts-and...

Emacs has globally shared buffer state amongst the frames that share the same "base frame" (no idea what this is called) or the same socket (could be wrong here).

Anyway, you can start N emacs instances and they can all have individual buffer states.

Emacs is not primarily a TUI program (although it does have a TUI with the -nw). The TUI version of emacs lacks visual customizability and introduces unnecessary overhead (terminal!). Use the GUI.

Text insertion lag is something I haven't experienced since 2019. Config issue?

project-find-file might be slow because of low gc-cons-threshold. I know consult gets around this by temporarily raising the threshold. These days, you can use the feature/igc branch to make these operations faster (although they are pretty fast anyway).

If you think emacs lacks <fundamental feature X>, think again!

> I think having a globally shared buffer state, etc. is an antifeature.

Maybe, but I'd like to hear why you think this is such an antifeature for a single-threaded application.

Given the extra resources available these days, for example, why not just bring up a stand-alone ERC instance for chatting, if shared state is a concern?