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

Previous Next

Full log

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

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: Re: bug#56393: Actually fix the long lines display bug
Date: Tue, 19 Jul 2022 14:33:35 +0000

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

>> Fine, but then you'd have to tell me how to do that in another way 
>> (that is, how to not trigger the long line detection code when the 
>> buffer has only changed a little), or to convince me that the 13 ms 
>> overhead is okay.
>
> That's not what I'm saying.  I'm saying that not recomputing the long 
> lines when the user types "C-u 100000 a" is not a catastrophe.
>

It is, at least if this is meant to be a full and complete solution to 
that problem, because the same happens for example with C-x i <a file with 
long lines>: the tick does not change "enough", long line optimizations 
would not be enabled, and Emacs would choke again.  Or if a user 
innocently types "cat <a file with long lines>" in a shell buffer without 
knowing what that file contains.

Previous Next

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