Re: Nested sit-for's

[Richard Stallman <rms@gnu.org>]

    >> What about the change that we discussed where nested sit-for calls
    >> should not wait longer than any of the outer calls??

I am not sure it is really a bug.  Whether this behavior is incorrect
depends on how you think of sit-for's purpose, and there is a natural
way to think of it which makes this behavior correct.  For the inner
sit-for fail to wait for the time specified seems clearly wrong.

My conclusion is that it is wrong for a timer to do a sit-for that
lasts any substantial time.  It should instead schedule a new timer.
As long as jit-lock-stealth-nice is a short period such as 0.5, its
sit-for cannot cause a big delay to anything else.

The potential problem I do see is that jit-lock-stealth-fontify will
keep looping as long as input-pending-p is nil.  If it were to run
from inside some other idle timer, that other idle timer would not get
control back until fontification is finished.  Making
jit-lock-stealth-fontify's sit-for return faster won't avoid this
problem, only reduce it, since jit-lock-stealth-fontify still would
not return until it finishes fontification.  The only solutions are
(1) that jit-lock-stealth-fontify reschedule itself instead of using
sit-for, or (2) that the other timer function avoid using sit-for.

If several timers try this sit-for trick, then no matter what we make
sit-for do, they can't all get the behavior they want, which is to do
some more processing at a certain time in the future.  The only method
they can all use that enables them all to get this behavior is that of
rescheduling timers.

It would work to have ONE timer that does sit-for if we make a rule
that no others can do so.  We could define jit-lock as this one
exception.  (This has the advantage of not involving any change in the
code, just comments and the Lisp Manual.)

What do people think of that?