GNU bug report logs - #56393
Actually fix the long lines display bug

Previous Next

Full log

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: 56393 <at> debbugs.gnu.org
Subject: Re: bug#56393: Resetting long_line_optimization_p to 0
Date: Tue, 19 Jul 2022 13:20:01 +0200

Gregory Heytings <gregory <at> heytings.org> writes:

>>
>> What I meant was resetting the flag without resetting the buffer.
>> For example in redisplay_window when it finds that the condition for
>> setting it true is no longer met.
>>
>
> It is indeed never reset.  It goes only in one direction: as soon as a
> buffer contains one "long enough" line, the specific optimizations are
> used, and the buffer continues to use them.

Okay.

>
> Such buffers are not common,

Right.

That's the reason I didn't want to tackle this problem in Emacs 21, BTW.
But I also did not have your idea at the time.

>
> I don't think it is necessary/useful to check after each iteration
> whether the buffer still contains long lines, especially given that
> these optimizations have a near-nil effect in buffers without long
> lines.

Correct.

Which leaves me with something to think about, of course: when redisplay
sets the flag in the buffer, then there's of course a time before that.
And the question is what can happen in that interval.  But not today.
I'll come back to you.


P.S. (for Michael Albinus, if he's still reading this thread >:-))

When replying to a message in Debbugs with 'F' (Gnus), the subject gets
changed to the original bug report subject.

Previous Next

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