> Why did you immediately set it to nil instead of trying to making it
> sufficiently large?  You said that some lines in the Logview buffer
> are long, but I bet they are never longer than, say, 100000
> characters.

How do I decide what is sufficiently large? With this optimization
Logview can fall into that infloop in fontification code, at which
point Emacs becomes completely frozen, with the only way out to
restart it. As have been determined in this thread, this is not a
bug. I still kinda want to avoid this non-bug, because it is a bit
disruptive to my work.

With long lines I can suffer slow and not-quite-responsive (but still
not hung to death) Emacs, which is much more bearable. Usually that
only happens when I open or grep something like a minified JS file by
mistake anyway.

For you this long-line optimization is probably very important, maybe
you often work with files that trigger this and make using Emacs a
pain without it. But for me it's a minor feature that I have barely
noticed, but that incidentally completely broke my normal workflow by
making Emacs seemingly randomly freeze (until I found time to debug
it, which was not easy as Emacs would not respond to anything).

> As I told you, the general fix will be to adapt Logview to handle locked
> narrowing, by explicitly unlocking the locked narrowing when it needs to
> access a larger portion of the buffer.  You were somewhat reluctant at
> that idea.

Maybe I misunderstood you. If I have to add a one-time adjustment to
the code to the effect of "unlock the narrowing it inside this block",
then it is fine for me. Now that I reread:

    > the "fully cooked" narrowing will not magically solve that
    > problem, though.  Logview will have to be adapted to deal with
    > the possibility of a locked narrowing.

I don't see implications that unlocking would be impossible. If I only
would have to use sth. like sketched (I don't insist on it looking
like this):

    (let ((disable-locked-narrowing-yes-i-know-this-is-bad-but-still t))
      (widen)
      ...
      )

once the branch is finished and merged (and that it would work for all
kinds of tags or whatever at once), then sorry for misunderstanding
and starting a heated discussion for nothing.

Paul

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

>
> >> already told you thrice that a simple way to fix your problem is to set
> >> long-line-threshold to a larger value (or to nil).
> >
> > Thanks, I added  `(setf long-line-threshold nil)' to Emacs startup
> > configuration file a couple of days before. But unless I'm missing
> > something, this is not a fix, only a workaround.
> >
>
> Why did you immediately set it to nil instead of trying to making it
> sufficiently large?  You said that some lines in the Logview buffer are
> long, but I bet they are never longer than, say, 100000 characters.
>
> As I told you, the general fix will be to adapt Logview to handle locked
> narrowing, by explicitly unlocking the locked narrowing when it needs to
> access a larger portion of the buffer.  You were somewhat reluctant at
> that idea.