bug#51490: Show an indicator when Emacs is busy somewhere in the Emacs window

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 22 Sep 2022 15:57:04 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, stefan@marxist.se, 51490@debbugs.gnu.org
> 
> >> I'm thinking aloud here, sorry if it isn't useful.  But I think we have 
> >> at least one similar occurrence: XTflash.
> >
> > Which part of it seemed similar to what is being discussed here?
> 
> The fact that a portion of the frame is modified without a complete 
> redisplay of the frame, through primitive drawing functions?  Am I missing 
> something?  Would it not be possible to draw a busy indicator at a fixed 
> position of the frame with XDrawRectangle for the background, followed by 
> XDrawPoints for the foreground?

It should be possible, yes.  I just said that we don't have such an
infrastructure yet, it needs to be written first.  When someone does
write it, they will have to deal with the issue of what kind of
drawing do we allow there; for example, a 1-pixel line is easy, but is
unlikely to be visually appealing.

And the main problem this will have to solve is this: whatever you
draw behind the back of the display engine will run the risk of being
wiped out when the next redisplay cycle kicks in.  XTflash doesn't
have that problem because it is invoked from Lisp, not from an async
signal handler.

> >> or decide to do something different and use a specific function to set 
> >> these two colors without going through the whole face machinery, 
> >> something like (set-busy-indicator-colors FOREGROUND BACKGROUND).
> >
> > As soon as we allow set-busy-indicator-colors or somesuch, we have a 
> > problem with Lisp programs doing that exactly when there's time to 
> > redraw the indicator.
> 
> We could specify that set-busy-indicator-colors is only meant to be used 
> in init files, for example.

Good luck with getting that past our users!