bug#57804: An infinite loop in a `fontify-region' function causes Emacs to hang indefinitely

[Paul Pogonyshev]

> > or is it "you have to rewrite, because we have decided so"?
>
> That's not how I would present things, no.

It doesn't matter how you would present it, it's the result that
matters.

> Why does Logview infloop when
> locked narrowing is in effect?  This might be a bug in Logview

Because it assumes that after `widen' all restrictions are gone.  If I
do

    x = 10 + 20
    if (x == 25)
      throw new Error ();

and this results in an error, then the bug is not _in my code_.

If I need to treat every function as "pretty please, do this, but if
you don't, it's fine, I'll do something else", my code will inflate
tenfolds and will still not achieve its goals.

> fontification-functions / jit-lock-function is not supposed to access and
> modify a large portion of the buffer.

"Is not supposed" is not the same as "must not do, else everything
crashes".

> I don't use Logview, and you did
> not give a detailed recipe to reproduce the issue

Recipe is obvious:

    (widen)
    (if (/= (point-min) 1) (error "WTF is going on?"))

Why Logview needs to access the full buffer at any time? Because it
operates lazily. It expects that log files are several megabytes and
therefore doesn't parse them fully. There are at least two passes:
first splits the file into entries, second fontifies. The first can be
used for other reasons too. In other words, when fontification comes
around, the relevant buffer part may not be even split into entries
yet, so fontification code calls the splitting code first. Logview
also almost never moves the point internally (because that might be
slow in huge buffers), instead it needs to be able to query text
properties anywhere. And with narrowing this is impossible.

Frankly, I don't see why I need to tell you _why_ I need this. Even if
I write five pages explaining every single detail, all things I have
considered in the years this mode had been written (with one major
refactoring for performance reason), I know the answer: "Yeah, but you
could do X or Y instead". Of course, I have never thought about that,
yeah. Of course I have just chosen this approach randomly.

You either accept that there _might_ be something you haven't thought
about, you have never discovered or simply never needed. Or you
don't. Then you just say: "Do it this way! For me it's enough,
therefore it _must_ be enough for everyone. Or if it's not it's their
problem and I don't care.".

Paul

On Thu, 15 Sept 2022 at 17:10, Gregory Heytings <gregory@heytings.org> wrote:

>
> Is it technically impossible to lift narrowing restrictions in Emacs 29
>

It is not, you can choose a radical approach and long-line-threshold to
nil.  Or you can choose a less radical approach and set
long-line-threshold to a larger value (as I already told you twice IIRC).

>
> (as in, something would break),
>

Locked narrowing is one part of the solution to the long lines bug in
Emacs, so something could indeed break if you turn that solution off.

>
> or is it "you have to rewrite, because we have decided so"?
>

That's not how I would present things, no.  Why does Logview infloop when
locked narrowing is in effect?  This might be a bug in Logview:
fontification-functions / jit-lock-function is not supposed to access and
modify a large portion of the buffer.  I don't use Logview, and you did
not give a detailed recipe to reproduce the issue, so it's difficult to
give more precise advice.