GNU bug report logs - #56683
29.0.50; long lines fix doesn't work correctly when lines are truncated

Previous Next

Full log

View this message in rfc822 format

From: Gregory Heytings <gregory <at> heytings.org>
To: Andrey Listopadov <andreyorst <at> gmail.com>
Cc: 56683 <at> debbugs.gnu.org
Subject: bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated
Date: Fri, 22 Jul 2022 06:34:23 +0000

[Message part 1 (text/plain, inline)]

Thanks again for your comments.

>
> It depends, occasionally there are lines with JSONs maybe one third of 
> the size of the mentioned dictionary.json.  But these are rare cases, 
> most of the time the longest lines are about 3000 characters wide, I 
> guess I have to measure it next time.  So probably a smaller amount than 
> 10000 to enable optimizations is welcome.
>

FTR, in buffers with lines that are "only" 3000 characters wide, long line 
optimizations are not turned on by default (see long-line-threshold, which 
is set to 10000 by default), such buffers should behave "well enough" 
without them.

>
> One particularly interesting situation is when there are logs which span 
> such long lines on every line, e.g.:
>
>   1 log-line-with-1800-chars→
>   2 log-line-with-3000-chars→
>   3 log-line-with-2000-chars→
>   4 log-line-with-1500-chars→
>     ...
> 1830 log-line-with-1500-chars
>
> In this case, if I wasn't using truncation I would see only the first 
> line of the log, wrapped around and taking all screen space, but since 
> lines are truncated, I have ~70 very long lines displayed on screen.
>

I understand.  It's an interesting use case.

>
> I've taken dictionary.json, and used C-u 70 M-x duplicate-line, and it 
> does seem to perform well (or at least Emacs doesn't hang completely), 
> but there are some occasional slowdowns (Probably because of 
> show-paren-mode).
>

At the moment I think it would be better to advise against using truncated 
lines for such pathological files.  As Eli just said, it would probably be 
rather complex to remove the hard-coded limit in the Emacs display engine.

Previous Next

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