Emacs graphical frontends / responsiveness

[Jordan Ellis Coppard <jc+o.emacs@wz.ht>]

Hello friends,


I've been using Emacs as properly as I can for the past year-ish (read: 
all-in instead of bailing out constantly) after circling around the edge 
of the pool for a few years.

Overall I think I like it, although I am still less productive than I 
would be in say an IDE from JetBrains or Helix (a TUI editor). I'm sure 
I can close that gap as I tinker with Emacs more and more.

One thing that bothers me without fail is how slow, visually, Emacs is. 
I can often times type faster than the GUI can keep up, with noticeable 
hitching and delays from when I have typed a character to the point 
where I see it in a buffer and so forth. This is probably one of the 
biggest things ruining my experience because no matter how focused I am 
on the task at hand seeing this behaviour always rips me out of focus. 
That's also why I feel less productive with Emacs.

I run a fairly lean Emacs configuration, however even basic behaviour 
under `emacs -Q` is slow. Take `show-paren-mode` with `show-paren-delay` 
set to 0; Helix, VS Code, Neovim are able to instantly highlight matched 
brackets as I move my cursor around. With Emacs there is a noticeable 
delay (yes even with a delay of 0 and in `emacs -Q`). Often times I can 
type faster than the minibuffer input area can handle when filtering 
completion candidates e.g. `C-h o`.

I don't want my editor (or whatever specific title you'd like to apply) 
to EVER not immediately respond to input unless it's crashed. I don't 
want my editor running locally only accessing local resources to feel 
like an ssh connection with 200 ms of latency when nothing else, nor any 
other editor I've tried, does. I understand if I provide some input that 
I may be asking it to do heavy lifting and that eventually it will get 
back to me with the result (that's fine), but blocking everything else 
while that happens is frustrating as I have described above.

I recently saw in this mailing list Yuan benchmark character insertion 
into a buffer (with syntax highlighting) at around ~30 ms (if I recall 
correctly). That's an update rate of 33 times a second, with presumably 
(for benchmarking's sake) nothing else going on; thus one would assume 
even lower update rates if you use a few features here and there 
built-in or otherwise. Emacs struggling to update display in under 16 ms 
was... shocking to see.

I also recently read this post: 
https://gist.github.com/ghosty141/c93f21d6cd476417d4a9814eb71dd46e  -- 
which left me feeling quite sad (if it is accurate) regarding the 
internals surrounding the GUI and so how apparently needlessly difficult 
in today's age it would/will be to improve (over how it currently is). I 
understand the historical legacy.

So I ask: is it possible that Emacs' GUI be decoupled from the lisp core 
such that updates can happen as fast as possible (less perceived delay), 
and that the (what I gather from the above post) rube goldberg display 
internals be remade from scratch, or more likely, a new frontend (from 
scratch) as an alternative?

I don't ask as a "please do this for me".

I'll get involved but if the answer ahead of time is a "no it's never 
going to happen even with a completely working patch in future" then I 
think it'd best for me to abandon Emacs. I have ADHD and the visual 
hitching and lack of responsiveness to input drives me insane. I fear 
it's something I'll never be able to get over and in a world of less 
configurable vs. visually hitching and slow I would rather take the former.

I realise this email has been fairly critical so far. I have said all of 
this without malice, I just feel it prudent to describe how important 
this is (at least to me) by not mincing words.

Besides the criticisms: Emacs, so far, is amazing. I can make it do 
whatever I want, however I want, and mould it to be uniquely my own 
which is something I cannot do with anything else. The effort from 
scores of people over ~40 years as well as the continued effort shows. I 
can't imagine so much effort or such an enduring project.

But as I've said this behaviour (of Emacs) ruins it for me and I don't 
think I'll ever be able to get over it so at this juncture I'd rather 
help contribute and improve Emacs for myself and others and I hope 
that's something this email can be the genesis of.


Regards,
Jordan