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!
> 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.
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).
Startup time does not matter, use the daemon. Opening a new frame is ~instantaneous.
I practically live in Emacs and it's not slow at all. It's very zippy, and my setup isn't the lightest!
There's a new branch (feature/igc) with incremental garbage collection (via MPS) that makes routine actions faster. I've been using it and it has been incredibly stable and has completely eliminated stutters (which used to happen very infrequently, but were present). Also, to me, it seems like it improves latency. The cursor feels more responsive.
> I practically live in Emacs and it's not slow at all. It's very zippy, and my setup isn't the lightest!
yeah, that's been my experience as well, particularly since upgrading to releases 29 and 30 where native compilation was enabled by default.
honestly the only place where it's slow it's when i'm editing terraform files, but that's because it needs to boot the terraform language server, and only on the first file of the project.
This article is a portrait of three Sociopathic Zoomers : the twitter poster, the cheating app guy and the teenage scammer. All three are net negatives to society.
Depends on the amount of effort you put into them, and the kind of work you do on the computer. Regular users should stick to regular keyboards. Power users (like programmers) can spend a few months with a split keyboard and customize their layout and come out the other side with a personal brain-computer interface (fingers + keyboard).
Many people (including myself) use small split keyboards and are very happy with them. You don't need a kinesis to avoid wrist movement, DIY keyboards (like the corne) work just as well.
reply