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

Previous Next

Package: emacs;

Reported by: Gregory Heytings <gregory <at> heytings.org>

Date: Tue, 5 Jul 2022 08:50:02 UTC

Severity: normal

Done: Gregory Heytings <gregory <at> heytings.org>

Bug is archived. No further changes may be made.

Full log


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

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: Re: bug#56393: Actually fix the long lines display bug
Date: Wed, 20 Jul 2022 16:23:16 +0300
> Date: Wed, 20 Jul 2022 13:06:59 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: gerd.moellmann <at> gmail.com, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
> 
> 
> >
> > Yes, thanks.  Perhaps add a comment inside modiff_incr explaining why we 
> > do it logarithmically.
> >
> 
> You mean, something like: "Increase the counter more for a large 
> modification and less for a small modification, but increase it 
> logarithmically to avoid increasing it too much for a large 
> modification."?

No, I mean explaining why we want to be more sensitive to small
modifications than to the large.  IOW, why we want to avoid linear
increments.

My original proposal to limit the increment was because I wanted to
avoid overflowing the counter when several very large insertions are
made.  If this is the only reason, I think we should say that in a
comment there.

> BTW, I think the threshold to trigger the long lines check in 
> redisplay_window could be increased a bit.  That is, instead of using 
> "MODIFF - UNCHANGED_MODIFIED > 4" I think we could use "> 8".  That would 
> exclude a few more common editing operations, e.g. C-k in a buffer with 80 
> columns.  WDYT?

I have no real experience on which to base my opinions, so feel free
to make the change.  Like I said, the threshold should be tuned, and
we may yet find the need to change it more than once.

> > (Hmm... should we say something about this in NEWS?  Not that I expect 
> > some code out there depend on the exact increments in MOFIFF...)
> >
> 
> That would be very surprising, because they are in general unpredictable, 
> and different depending on the context; e.g. MODIFF is incremented when 
> font locking is enabled.

OK, let's wait until someone hollers, if they do.




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.