On Sun, Mar 23, 2025 at 3:37 AM, Eli Zaretskii < eliz@gnu.org > wrote:

> 
> 
>> 
>> 
>> Cc: gerd. moellmann@ gmail. com ( gerd.moellmann@gmail.com ) , alan@ idiocy.
>> org ( alan@idiocy.org ) , 77039@ debbugs. gnu. org ( 77039@debbugs.gnu.org
>> ) Date: Sun , 23 Mar 2025 12:13:10 +0200
>> From: Eli Zaretskii < eliz@ gnu. org ( eliz@gnu.org ) >
>> 
>> 
>> 
>> So in summary, I don't see anything abnormal here. If we want to keep the
>> only-current-line-changed optimization in redisplay_internal, someone will
>> have to come up with a smarter test for when line numbers are shown. I
>> think the underlying problem is that when the line number of the current
>> line becomes large enough to require more columns for line-number display,
>> we must redraw the entire window to avoid the problem with shifting or
>> line number described in https:/ / debbugs. gnu. org/ cgi/ bugreport. cgi?bug=54091#5
>> ( https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54091#5 ).
>> 
>> 
>> 
> 
> 
> 
> To clarify: this should not cause any flickering, AFAIU, because the
> comparison of glyphs in subroutines of update_frame is supposed to find
> that everything on the glass is already up-to-date and there's no need to
> draw anything. So flickering, which happens because portions of the window
> are actually redrawn on the glass, should not happen in this case.
> 
> 
> 
> 

Right, I don't observe any flickering. Am I correct that it is only comparing the glyphs on the current line? If so, that doesn't seem like a huge problem, even though it is (in most cases?) technically extra work.

Aaron