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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: gerd.moellmann <at> gmail.com, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
Subject: bug#56393: Actually fix the long lines display bug
Date: Tue, 19 Jul 2022 05:34:45 +0300

> Date: Mon, 18 Jul 2022 20:14:21 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: gerd.moellmann <at> gmail.com, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
> 
> 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.

Why just "added"?  Deletion of characters can also create long lines,
if the deleted characters are newlines.

Also, what if since last redisplay N characters were deleted and N
other characters were added?  Isn't there a good chance that the long
line optimizations could now be needed in that case?

BUF_CHARS_MODIFF will catch all of these, while just looking at the
buffer's size won't.

And that's on top of the main reason: BUF_CHARS_MODIFF exists for a
long time, so introducing yet another similar counter sounds like not
the best idea to me.

Previous Next

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