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

From: Eli Zaretskii <[email-masked]>
Date: Sun, 30 Apr 2023 17:42:49 +0300

> Cc: [email-masked]
> From: Aaron Jensen <[email-masked]>
> Date: Sun, 30 Apr 2023 10:25:59 -0400
> 
> On Sun, Apr 30, 2023 at 9:25 AM Po Lu <[email-masked]> 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.