bug#45652: so-long mode not triggered despite big file with very long lines

[Phil Sainty]

On 12/01/21 7:39 am, Lars Ingebrigtsen wrote:
> Have you considered adding a C-level primitive that just looks at the
> entire buffer?  It should be reasonably simple and very fast -- just
> count areas between "\n"s, skipping the buffer gap.  We don't have to
> care about characters as such, I think, so this should be massively
> faster than counting line lengths in Lisp.

FYI, this also triggered a memory from several years ago:
https://lists.gnu.org/archive/html/emacs-devel/2016-07/msg00761.html

Stefan's thought at the time was:
> I wonder if we could improve the detection part with some help from
> the C code.  I'm thinking of trying to keep track of "the last \n
> before point" and calling a hook whenever this is larger than a
> threshold.

I never followed up on that (I ended up shelving the idea of releasing
so-long.el for a couple of years or so, as my own use-cases at the
time turned out to be due to one specific badly-behaved library which
had already been fixed upstream, so for a while I thought it might not
be as useful as I'd originally thought).


On 2021-01-12 10:07, Lars Ingebrigtsen wrote:
> > I can give writing something like that a shot...  It could return, 
> > say,
> > the length of the longest line, and the number of lines?  The median
> > line length would be nice, but would be slower.
>
> Mean would be easy, and standard deviation would be possible (but
> require two passes, I guess?)

I'm not sure that so-long itself would find it useful to know any kind
of averages, but longest line is obviously useful, and the number of
lines sounds more or less like a freebie, and might be useful too.


-Phil