[jonpalmisc]

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.

[chriswarbo]

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

[precompute]

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!

[MereInterest]

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

Can you elaborate on this? I tend to use emacs exclusively in the terminal, since I'm often using them on remote workstations. For remote workstations, I can (a) open files using TRAMP, (b) open a remote GUI with X11 forwarding over SSH, or (c) open a remote TUI. TRAMP doesn't always play nicely with LSP servers, and remote TUIs are much, much more responsive than X11 forwarding.

Locally, the performance of emacs depends far more on the packages I load than on the GUI vs TUI, so I'm interested in hearing what overhead there would be.

[precompute]

Yes, emacs is equally performant in GUI and TUI. And frames can be opened in both GUI and TUI on the same socket.

For me, TUI is a dealbreaker because:

- No mixed-pitch support: I use mixed-pitch fonts in org-mode buffers and in outline faces in prog-mode buffers. And fonts are just plain nicer on the GUI, and it's much better to look at.

- No SVG support: (I might be wrong about this) I have a custom modeline with SVG artifacts and the artifacts fail silently on the TUI

- Keybind conflicts: I am not used to accounting for the terminal's keybinds. Also, I use xfce4-terminal, which does not support the Hyper modifier (which I use extensively).

[finaard]

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.

[ragall]

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

[jonpalmisc]

> You seem to think that the interface obliges a program into a certain performance pattern.

I think all software (or at least, any text editor) regardless of interface type should launch instantly. But it's more unjustifiable with TUI programs.

[ragall]

Nah. Here's a counter example: the TUIs that IBM wrote for many old store chains like Home Depot. They're at least an order of magnitude faster to operate for cashiers compared to web UIs but they're somewhat slow to start due to the caching and self-checks they do. This obsession with quick boot is more of a personal preference you have than a necessity.

[qubidt]

An inane point. Obviously it's a "preference" rather than a "requirement" that my text editor boot in less than 30 seconds. But it's also not a functional requirement that Home Depot's POS terminals take a long time to start. If you could do the same checks and caching in a few hundred milliseconds it would only improve the usability for the cashier. You haven't made a case for why some user interfaces shouldn't start instantly, only that their slow start-up _might_ be justified

[ragall]

> If you could do the same checks and caching in a few hundred milliseconds it would only improve the usability for the cashier.

No it wouldn't. Those interfaces are permanent and only get restarted once a day or if the hardware has to be rebooted. Same for Emacs: there's absolutely no need to start the editor every single time.

> You haven't made a case for why some user interfaces shouldn't start instantly

I'm not making any case, we're not in court. Startup time is irrelevant and your fixation with it is really funny (up to a point).

[smitty1e]

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

[dietr1ch]

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