GNU bug report logs -
#56393
Actually fix the long lines display bug
Previous Next
Full log
Message #500 received at 56393 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 19 Jul 2022 05:39:24 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: gerd.moellmann <at> gmail.com, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
>
> 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.
Yes, it does: it allows you to keep track of changes to the buffer
text only, ignoring any other changes (like faces, overlays, etc.)
which affect the buffer's modified status. The number itself is not
interesting, the only thing that is interesting is when the number
goes up -- this means the buffer text was changed in some way.
> 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.
We could indeed keep using MODIFIED != UNCHANGED_MODIFIED (and I'm not
really sure why you decided it was not good enough: can you describe
the problems using it?). Alternatively, we could add a new member of
'struct buffer_text' called, say, unchanged_chars_modiff, and use it
instead of MODIFIED != UNCHANGED_MODIFIED in the same way as we use
MODIFIED != UNCHANGED_MODIFIED.
My point is that if you want the member you added, unchanged_size, to
be as responsive to text changes as BUF_CHARS_MODIFF, you will need to
add code to increment it in all the places where we already do that
with BUF_CHARS_MODIFF, and that sounds like redundancy, since we don't
really care about how many characters were added/deleted/replaced.
This bug report was last modified 3 years and 33 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.