GNU bug report logs - #63187
30.0.50; Tail of longer lines painted after end of nearby lines on macOS

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>
Cc: luangruo <at> yahoo.com, 63187 <at> debbugs.gnu.org
Subject: bug#63187: 30.0.50; Tail of longer lines painted after end of nearby lines on macOS
Date: Sun, 30 Apr 2023 17:42:49 +0300

> Cc: 63187 <at> debbugs.gnu.org
> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Sun, 30 Apr 2023 10:25:59 -0400
> 
> On Sun, Apr 30, 2023 at 9:25 AM Po Lu <luangruo <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.