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

[Drew Adams]

(Caveat: Not really following this thread.)

> 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.
>    The total mode line render time is also recorded.
> 
> 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....
> 
> 3. After "debounce" time since the last "suspend", all the :eval are
>    processed in full again, generating up-to-date mode-line.

Assuming that's feasible, and might be done
(e.g. Eli's mail suggests it's not so easy):

Instead of just doing that automatically,
or just letting users turn it on/off, why
not give users more of a heads-up and more
control over how to handle the problem?

When you've detected that some mode-line
processing (e.g. with :eval, but maybe even
otherwise) takes "too long" (based on a
user-configurable threshold), take whatever
action the user has previously chosen, e.g.:

1. What you describe: automatic debouncing.
2. Highlight the mode-line in some obvious
   way, as long as the problem exists.
3. #1 & #2: highlight and debounce.
4. Prompt user for what to do.
5. Invoke some user-defined or 3rd-party
   library-defined function.  (One example
   could be to report the problem to the
   library maintainer.)
6. ...

User choice could be by config (option).
Or it could be by user code or 3rd-party
library code (e.g. mode-line libraries
could provide alternative behavior).

That's off the top of my head, obviously.
The idea is to, in some way:

 * Let users know what's happening.
 * Give users some control over what to do.