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

Previous Next

Full log

Message #527 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: Tue, 19 Jul 2022 16:56:39 +0300

> Date: Tue, 19 Jul 2022 13:42:26 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: gerd.moellmann <at> gmail.com, larsi <at> gnus.org, 56393 <at> debbugs.gnu.org
> 
> > So you want to call the loop only when the buffer changed by two or more 
> > characters?  Did you try something like
> >
> >  MODIFF > UNCHANGED_MODIFIED + 1
> >
> > ?  (This could be optimized further to use a margin larger that 1.)
> 
> That doesn't work alas, otherwise I would have used that of course. 
> After C-u 100000 a, MODIFF - UNCHANGED_MODIFIED == 1 in a buffer without 
> fontification and == 2 in a buffer with fontification, which does what it 
> promises: it tells you that the buffer has been changed, but not how much.

Why is that a problem?  For this feature, we don't need the exact
number of modifications in character units.

> I pushed an improved version of the heuristic, which uses both MODIFF / 
> UNCHANGED_MODIFIED (to catch editing operations like M-% C-q C-j RET SPC 
> RET) and the buffer size to decide whether a new detection should be 
> performed.

Fine by me, but I think this is over-engineered.

Also, please add a comment there explaining the heuristics, including
the cases we know about where the counters could behave "strangely" or
fail to catch changes.

Thanks.

Previous Next

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