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

Previous Next

Full log

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
Subject: Re: bug#56393: Actually fix the long lines display bug
Date: Mon, 18 Jul 2022 20:14:21 +0000

>> And the answer is no.  (I tried to use it, but did not remember the 
>> reason why it was not usable in this context while writing my previous 
>> reply.) I don't know what BUF_CHARS_MODIFF records
>
> What BUF_CHARS_MODIFF records is documented in the doc string of 
> buffer-chars-modified-tick.
>

Yes, I know.  But, even if it had no bugs, the doc string does not seem 
promising for the present task AFAICS:

Each buffer has a character-change tick counter, which is set to the value 
of the buffer's tick counter (see `buffer-modified-tick'), each time text 
in that buffer is inserted or deleted.  By comparing the values returned 
by two individual calls of `buffer-chars-modified-tick', you can tell 
whether a character change occurred in that buffer in between these calls.

What I'm interested in in this case is not simply "whether a character 
change occurred", but "how many characters were added in the buffer".  I 
want to calculate whether the long line optimizations should be enabled if 
and only if two or more characters were added in the buffer since last 
redisplay.  That is, neither if only one character was added in the buffer 
(which is what happens during normal typing), nor if characters were 
removed from the buffer.

Previous Next

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