I love Emacs, but it really just fails to be effective for me when I work on monorepos and even more so, when I'm on tramp.
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.
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.
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)
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.
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.
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...
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!
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.
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?
$ gtime /opt/homebrew/bin/emacs --batch --eval '(princ (format "%s\n" emacs-version))'
30.2
0.07user 0.03system 0:00.13elapsed 78%CPU (0avgtext+0avgdata 46064maxresident)k
$ /usr/bin/time ~/bin/emacs --batch -eval '(princ (format "%s\n" emacs-version))'
30.2
0.02user 0.01system 0:00.04elapsed 95%CPU (0avgtext+0avgdata 57728maxresident)kI agree, but there's ways around it. On my machine the Emacs daemon is ready before I even log-in (lingering [^0]).
I think I only restart the daemon when I update emacs and its packages, and yeah, Emacs and Spacemacs are slow, but do not slow me down.
[^0]: https://wiki.archlinux.org/title/Systemd/User#Automatic_star...
So the miniscule increase in start time is a non issue
For me, the best performance improvement has been handling long lines; e.g. Emacs used to become unusable if it was given a line of around 1MB. Since I run lots of shell-mode buffers, that would happen frustratingly-often. My workaround was to make my default shell a script that pipes `bash` through a pared-down, zero-allocation copy of GNU `fold`, to force a newline after hitting a certain length (crossing a lower threshold would break at the next whitespace; hitting an upper threshold would force a break immediately). That piping caused Bash to think it wasn't interactive, which required another work-around using Expect.
Thankfully the last few versions of Emacs have fixed long-line handling enough for me to get rid of my awful Rube-Goldberg shell!
On my old Ryzen 3600X running Arch it's a lot faster. Does the UI eat so much performance on OSX?
$ time emacs -Q -e kill-emacs
real 0m0.076s
user 0m0.058s
sys 0m0.018s
$ time nvim -es --cmd 'vim.cmd("q")'
real 0m0.028s
user 0m0.005s
sys 0m0.003s
> vim still is a lot faster though.
you might want to make sure you're comparing apples to apples though. the "emacs" command most likely is going to load the GUI emacs so a lot of gui libraries (if you're running a recent emacs then even GTK libraries) whereas the nvim command isn't going to load gui libraries at all.
maybe try with a non-gui version of emacs (or maybe calling emacs -nw)
$ time nvim -es --cmd 'vim.cmd("q")'
real 0m0.057s
user 0m0.016s
sys 0m0.017s
$ time emacs -Q -e kill-emacs
real 0m0.230s
user 0m0.165s
sys 0m0.064s
$ time emacs -nw -Q -e kill-emacs
real 0m0.095s
user 0m0.057s
sys 0m0.017sTried it anyways, looks the same:
$ time emacs -nw -Q -e kill-emacs
real 0m0.075s
user 0m0.062s
sys 0m0.013sAltough I'm not using Emacs.app.
Not for the parts of it I use.
Like what? Emacs is written in C and there are ports of it out there (all half-abandoned). Emacs, the way it exists, works very well.
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.