Re: Debouncing slow mode line constructs (was: Emacs design and architecture. How about copy-on-write?)

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: dmitry@gutov.dev, luangruo@yahoo.com, acm@muc.de, incal@dataswamp.org,
>  emacs-devel@gnu.org
> Date: Fri, 22 Sep 2023 10:23:47 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How do you propose to evaluate just portions of the mode line?  What
> > will the :eval whose processing is bypassed yield, and how will that
> > affect processing of the rest of mode-line-format, given its
> > highly-recursive processing structure and the fact that the text
> > produced by this processing is laid out as it is produced?
> 
> What I have in mind is the following:
> 
> 1. Every time Emacs processes :eval construct it (a) measures the time
>    taken; (b) caches return value.

This needs to somehow identify each :eval and record its execution
time.

> 2. If the total render time exceeds configurable threshold, processing
>    the most time-consuming :eval constructs will be suspended until
>    "debounce" time since the last full processing.
> 
>    By "suspended", I mean that cached :eval value is reused instead of
>    invoking :eval again. Possibly, not reused verbatim, but by replacing
>    the cached value with some kind of placeholder that has the same
>    total height/width as the cached value.

This needs also to cache the last value of each :eval.

It also assumes that these elements are quasi-static, for long enough
time to decide which one(s) are slow and reuse their cached values.
But mode-line-format is just a variable, and a Lisp program can
legitimately change it at a high frequency, which will defeat any
useful caching (because the :eval elements change and no longer match
their cached entries).  Moreover, a Lisp program can decide to
deliberately defeat this caching by relatively simple measures.  Last,
but not least, all this additional processing will make mode-line
display slower even if all the :eval forms are completely benign.

Also, Emacs has a tradition of leaving Lisp programs enough rope to
hang themselves, as long as they don't cause crashes and other
catastrophic outcomes.  This proposal will prevent a Lisp program in
:eval from doing its thing simply because we don't like its timing
(which, btw, depends on the CPU power, so a threshold that is an
absolute number of seconds is not necessarily the best idea).  In some
quarters, this could be seen as breaking the contract.

The example with an external Git command is very relevant: using a
cached value could present to the user completely misleading
indications.

So I think this is a lot of trouble for little gain, and could be also
against our long-standing policies.