GNU bug report logs - #77039
31.0.50; Flickering on macOS

Previous Next

Full log

Message #146 received at 77039 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: alan <at> idiocy.org, 77039 <at> debbugs.gnu.org, aaronjensen <at> gmail.com
Subject: Re: bug#77039: 31.0.50; Flickering on macOS
Date: Sun, 23 Mar 2025 09:58:33 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  alan <at> idiocy.org,  77039 <at> debbugs.gnu.org
> Date: Sun, 23 Mar 2025 05:56:41 +0100
> 
> > Repro from emacs -Q:
> >
> > (defun foo ()
> > (Interactive)
> > (global-display-line-numbers-mode)
> > (term "/usr/bin/yes")
> > (switch-to-buffer "*scratch*"))
> >
> > Aaron
> 
> Thanks! I think I see now what's going on.
> 
> redisplay_internal has this (line numbers may differ):
> 
> xdisp.c:
> 17368       && (NILP (Vdisplay_line_numbers)
> 17369           || EQ (Vdisplay_line_numbers, Qvisual))
> 
> This means that certain redisplay optimizations that make redisplay
> particularly "cheap" are not tried, depending on line number display.

See bug#54091.

> Instead the more expensive redisplay methods are used that consider
> whole windows or parts of them and so on. Or, in other words, line
> number display can make redisplay less of a nop.

Yes, and there's little wonder it's so: certain changes in the buffer
and point position could potentially have effect on line numbers of
lines that are not involved in the change, so more thorough redisplay
is needed.

Previous Next

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