bug#38407: 27.0.50; infinite loop with display of large file without newlines

[Eli Zaretskii]

> Cc: pieter@vanoostrum.org, 38407@debbugs.gnu.org
> From: Phil Sainty <psainty@orcon.net.nz>
> Date: Fri, 6 Dec 2019 09:38:05 +1300
> 
> That 250 value is, as you note, incredibly small.

It is okay for a feature that is off by default.  I'm saying that
turning this on by default with such a low threshold would be wrong.

> As with many things in so-long it's something of a heuristic and
> trade-off.  The reasoning was that not all files with extremely long
> lines are just one line -- newline chars may still occur in the text
> for reasons other than the formatting of the file -- and so the
> question was: "given the context of a buffer in some prog-mode
> derivative, what length is "long enough" to indicate that we're not
> looking at a normal file, but something which probably contains
> minified code?

Did you try a different heuristic for detecting long lines, one that
isn't based on searching some portion of the buffer?  E.g., what about
going to a couple of random places and looking at the value returned
by current-column?

In general, searching for a newline is very fast in Emacs, so if you
use the right primitives, you should be able to scan quite a lot of
text before the time begins affecting responsiveness.