bug#42406: Mouse-wheel scrolling can be flickering

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Alan Third <alan@idiocy.org>,  konrad.podczeck@univie.ac.at,
>   42406@debbugs.gnu.org
> Date: Thu, 17 Dec 2020 12:47:17 -0500
> 
> > I think the issue is clear: mouse-scroll calls scrolling commands, and
> > all of the scrolling commands set update_mode_lines.  Why they do that
> > is explained by the comment in wset_update_mode_line:
> >
> >   /* If this window is the selected window on its frame, set the
> >      global variable update_mode_lines, so that gui_consider_frame_title
> >      will consider this frame's title for redisplay.  */
> 
> This comment makes sense in `wset_update_mode_line` because that
> function is for all cases where the "mode line / frame title" might need
> to be updated.
> 
> But in the present case, the only change is the w->start
> an the position of point: these are important enough to need to update
> the mode line (for the column&line number), but I don't think these are
> important enough to justify setting `update_mode_lines` to 42:
> not only other frames can't be affected, but even the current frame's
> title should basically never be affected either because it would be very
> unusual to have the line/column number as part of the frame title.

"Unusual" doesn't mean "unsupported".  For better or for worse, we
have documentation that is our contract with the users, and we cannot
unilaterally bail out of it, certainly not because the NS port is too
slow in updating the frame titles of 5 frames.

> The redisplay code does not guarantee that the mode-lines and
> frame-titles will always be fully automatically kept up to date:

Oh, yes, it does.  When that doesn't happen, it's a bug we need to
fix.  We just had something like this several months ago, where some
Lisp changed the face of a mode line in a way that required a very
thorough redisplay (because the height of the mode line changed
significantly).

> we do a good effort to keep it updated automatically, but there are
> various cases where we give up and require ELisp code to call
> `force-mode-line-update` explicitly.

force-mode-line-update should only be needed when changes in the mode
line are displayed in the middle of running Lisp code.  Anything else
is most probably a bug.

> We could decide that line/column numbers in frame titles fall
> into that category of things we won't always automatically update.
> 
> This said, a better fix would be to make it so `wset_update_mode_line`
> only causes the affected frame to be redrawn rather than all frames.
> The patch below should do that.
> Could you test it and see if the performance is good?

FWIW, I'm against such "fixes".  The current mix of frame-specific,
window-specific, and global flags is already a complex mess, where it
is extremely hard to understand which one of these should or does
trigger redrawing of something somewhere.  Adding some "assumed" logic
on top of that which is not really backed up by any clear path in the
code, but is just something we implicitly believe should happen, just
makes this mess less maintainable.

We should stop lumping heuristics one on top another, and instead
redesign this from scratch and make sure that every flag we set is
acted upon as intended, and only in situations we intend them to be
acted upon.  E.g., we should be able to set f->redisplay to a value
that means "update only the frame title".

> [ It can't be installed as-is: instead of `2` it should use the constant
>   `REDISPLAY_SOME`, but that requires moving the code around.  ]

I'm not against experimenting with replacing 42 by 32 or by
REDISPLAY_SOME etc., but I don't think we should install anything
along these lines, except if we need to fix a clear bug (i.e. a
redisplay glitch), which this one isn't.