Re: Emacs graphical frontends / responsiveness

[Jordan Ellis Coppard]

On 21/10/2024 4:30 am, Eli Zaretskii wrote:
> This is too general.  Please describe specific situations where this
> happens, and please accompany that by the list of optional features
> you have turned ON

If it happens again I shall, I've just replied in this general 
email-tree regarding a set of patches from Ben Simms I applied which 
(might) have fixed the issue; I also updated to HEAD (at the time) to 
rebuild Emacs so it could have been many things. I've experienced no 
such slowdown since then. As in my other reply if I do I'll perform a 
proper comparison (minimal reproduction, emacs -Q, config etc).

> show-paren-delay runs off the idle timer, which means it only kicks in
> when Emacs detects that it's "idle": it processed the last command and
> has no pending input.  Even if you set the delay to zero, the function
> which looks for and highlights the matching paren will only be called
> when Emacs is idle.  If you type fast enough, it will _never_ be
> called.  This is by design: most of such features (at least those of
> them that are well-designed) are coded to stay away and not to
> interfere with the fast typists among us.  I guess similar features in
> Helix, Neovim, etc. are based on different principles.  If you want an
> immediate highlighting of the matching parens in Emacs, you will need
> a different mode, not show-paren-mode.

It turns out I wasn't setting show-paren-delay correctly. I was setting 
it the same way I do other variables whose effects were being enacted 
but for some reason show-paren-delay was still it's default 0.125. Using 
setq-default before show-paren-mode now works as expected. It's been a 
while since I changed that but I believe I misread the docs on how to 
apply that setting so that's my mistake.

> I don't know if it's possible.  I do know that it is very hard,
> because Emacs wants to control the GUI completely -- and it must do so
> to let our users do the crazy, sometimes insane, stuff by writing
> relatively simple Lisp.  If someone knows how to decouple while
> keeping what makes Emacs Emacs -- such ideas, let alone code, will be
> very welcome.

Perhaps (as a barely educated guess) an actor-based approach might work? 
Similar to how Erlang's VM handles messaging. If I had the time I would 
give it a crack (and I think I'd need a lot of time, there's lots to 
learn) so beyond my simple statement there I don't think I have any 
further useful insight on approaches.

> Happy hacking!

I've replied (by proxy) regarding some of your points to other emails in 
this email-tree but also thank you for your reply! A very long one from 
me as I put this in my TODO pile and forgot when I further placed 100 
more things on-top.