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

Previous Next

Full log

View this message in rfc822 format

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: bug#56393: Actually fix the long lines display bug
Date: Tue, 19 Jul 2022 05:39:24 +0000

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

Indeed, somehow I missed that possibility.  I think a better heuristic 
would be: if more than one character was added or removed from the buffer, 
check whether the buffer contains long lines.  I want to avoid affecting 
normal typing as much as possible, even if the effect is small.

>
> Also, what if since last redisplay N characters were deleted and N other 
> characters were added?
>

You mean for example M-% C-j RET SPC RET?  Indeed, that's yet another 
possibility.

>
> 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.
>

To be honest, I don't really understand the purpose of BUF_CHARS_MODIFF. 
As the comment in buffer.h explains: "It is set to modiff for each such 
event, and never otherwise changed."  So it doesn't contain new 
information.  And it's inconvenient that you have to keep a copy of its 
previous value around, using MODIFIED != UNCHANGED_MODIFIED as I did 
earlier is much easier.

Previous Next

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