bug#56683: 29.0.50; long lines fix doesn't work correctly when lines are truncated

[Gregory Heytings]

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.