GNU bug report logs -
#56393
Actually fix the long lines display bug
Previous Next
Full log
View this message in rfc822 format
> Date: Tue, 19 Jul 2022 14:33:35 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: gerd.moellmann <at> gmail.com, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
>
> > That's not the problem you presented. You presented an opposite
> > problem: where inserting many characters bumps the tick by just 1. I
> > asked why that is a problem.
>
> We are miscommunicating. I was not telling you that the fact that
> inserting many characters bumps the tick by just 1 is in itself a problem.
> I was telling you that it makes that tick unusable for the present task.
Would it help if the tick were incremented by the number of inserted
(or deleted or replaced) characters (perhaps limited by some
reasonable value, like 1000)? That would be an easy change, and I
don't think it would break anything, since no current code relies on
the exact value of the tick, and the value you get after some
non-trivial operation on a buffer is generally unpredictable anyway.
Would that make the tick usable for this task?
You see, adding one more struct member to an object that we use all
over the place makes Emacs slower, because the object is larger and
thus takes more CPU cycles to copy. Granted, the slowdown is barely
noticeable, but these things add up over the years, so it is best to
avoid adding members if we can do without that. Thus, I'd rather
extend/improve the existing members than add new ones to fix issues in
the old ones.
If you agree, I can make such a change (but feel free to do it
yourself).
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.