bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS

[Eli Zaretskii]

> Date: Tue, 2 May 2023 23:36:34 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: aaronjensen@gmail.com, luangruo@yahoo.com, 63187@debbugs.gnu.org
> 
> On Tue, May 02, 2023 at 03:21:46PM +0300, Eli Zaretskii wrote:
> > > Date: Tue, 2 May 2023 11:14:56 +0100
> > > From: Alan Third <alan@idiocy.org>
> > > Cc: Eli Zaretskii <eliz@gnu.org>, Po Lu <luangruo@yahoo.com>,
> > >   63187@debbugs.gnu.org
> > > 
> > > Although, on reflection, your description sounds more like it's just
> > > not clearing the end of lines correctly, which wouldn't necessarily
> > > have anything to do with scrolling as such...
> > 
> > Can that happen in this case?  You will see in the code that (AFAIU)
> > it copies a rectangle whose width is the total width of the window, so
> > why would (not) clearing ends of lines be an issue?
> 
> It depends where the actual problem is occurring. It's hard to tell
> from the screenshots whether the rogue glyphs appear spontaneously in
> the middle of the window, or as a new line is scrolled onto the
> screen.

AFAIU, a new line scrolled into the screen is not handled by
scroll_run_hook.  Such a line is drawn anew, because there's no way we
have it in the glyph matrices and/or on the glass, by definition.

> As it scrolls further, Emacs no doubt is clever enough to know that it
> doesn't need to clear more than it drew for the last line, so the
> rogue characters at the end stay for the subsequent line, and so on
> until it hits a line that is long enough to wipe it all out.

I think you are describing something that happens only on TTY
terminals, if ever.  Emacs doesn't work that way on GUI terminals, and
if scroll_run_hook is indeed the culprit (that remains yet to be
proven, AFAIU), it is used in situations that are not necessarily
"scrolling" from the user POV.  This hook is run when Emacs determines
that some part of the display is exactly what is needed to be
displayed, but it is higher or lower on the screen than where it
should be.  Then (subject to some criteria of whether this
optimization is worth our while), we call this hook, which is supposed
to copy the pixels on the screen in the vertical direction, either up
or down.  It always copies the entire width of the window, so clearing
to EOL should not be the issue here, since the "cleared" pixels are
moved as well.