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

[Eli Zaretskii]

> Cc: 63187@debbugs.gnu.org
> From: Aaron Jensen <aaronjensen@gmail.com>
> Date: Sun, 30 Apr 2023 10:25:59 -0400
> 
> On Sun, Apr 30, 2023 at 9:25 AM Po Lu <luangruo@yahoo.com> wrote:
> >
> > Hmmm, this looks like a scrolling optimization bug.
> > I can't build the NS port right now, but if you insert:
> >
> >   return false;
> >
> > right after
> >
> >   /* Can't scroll the display of w32 GUI frames when position of point
> >      is indicated by the system caret, because scrolling the display
> >      will then "copy" the pixels used by the caret.  */
> > #ifdef HAVE_NTGUI
> >   if (w32_use_visible_system_caret)
> >     return 0;
> > #endif
> >
> > in `scrolling_window', in dispnew.c, does the problem go away?
> 
> Thanks, I will try this out. Is there any chance that it is related to
> the other bug I just reported, bug#63186?

No, no chance.  That bug was system-independent, while this one is
specific to macOS.  Also, while investigating bug#63186, I've
established that disabling scrolling_window optimization doesn't fix
the problem with redisplaying the mode line after mode-line-format was
nil.

> Is there anything specific to macOS that is involved in scrolling 
> optimization?

Not that I know of, and so if Po Lu's suggestion fixes the problem,
we'd need to understand how come scrolling_window fails on macOS.