bug#56682: Fix the long lines font locking related slowdowns

[Gregory Heytings]

> > > Before using a blunt tool like the forced-narrowing now in 
> > > `feature/long-lines-and-font-locking`, I think we should try and 
> > > figure out *why* the recipe below is so slow.
> >
> > It's not a blunt tool, it's an appropriate tool to help making sure 
> > that Emacs remains responsive when large files are visited.
>
> I'm not opposed to reducing the size of the text that's considered, but 
> doing it via narrowing is a blunt tool.

It isn't.  The only way to make sure that the size of the text is small 
enough is a forced narrowing from which fontification-functions cannot 
escape.

But let's try to be constructive.  You tell me that you're not opposed to 
reducing the size of the text, and that font-lock.el could enforce a 
smaller scope.  So could you please design a (Elisp) function (in 
font-lock.el) which, given a (beg end) with beg <= end in a buffer, 
returns a (beg' end') with beg <= beg' <= end' <= end that are better 
starting end end points for the forced narrowing?  That function would be 
run in handle_fontified_prop, before fontification-functions, and would 
have access to the whole buffer.

> > Think of it as POSIX's ulimits.
>
> That's also a blunt tool.

It isn't either.  It's a practical way to limit what a single process can 
do to make sure that what it does doesn't impact other running processes. 
At $job, each time I've seen a ulimit reached (usually the limit on open 
file descriptors), it was because of a bug.  I think I've seen a single 
exception, with a program that sometimes really needed to open more 
(temporary) files.  And even in that case the solution was not to remove 
the limit, but to raise it (from 1024 to 4096 IIRC).

> With the current narrowing they can't even know why the buffer is 
> narrowed and hence can't make an informed decision whether they should 
> maybe widen to look elsewhere.

There is no point to make such a decision, because they can't escape the 
narrowing.