Re: Partly deferred font-locking?

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: michael_heerdegen@web.de, emacs-devel@gnu.org
> Date: Thu, 12 Jan 2023 14:44:11 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I just tried
> >> 
> >> (while-no-input (let ((x 0)) (while t (cl-incf x) (when (> 3 (random 
> >> 1000000)) (message "%d" x)))))
> >> 
> >> and it does not block.
> >
> > Do you understand why?  Specifically: which code in Emacs caused us to
> > throw on input in this case?  And is that going to happen when Emacs
> > calls a C function that hits the disk?
> 
> AFAIU, maybe_quit throws the necessary signal as needed.
> 
> For external C functions that interact with disk, they will indeed not
> produce the signal. However, the signal will likely be thrown soon after
> disk interaction ends. In my experience, helm command that opens a
> number of files is successfully interrupted after populating a file
> buffer but before initializing the major mode.

My point is that when you call an expensive calculation inside
while-no-input, you are entirely at the mercy of the code run by the
body of while-no-input, wrt how soon after a keypress will
while-no-input be interrupted.  And since Michael was asking precisely
about such situations, I commented that it _might_ make Emacs less
responsive.