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

[Paul Pogonyshev <pogonyshev@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2905 bytes --]

> No, if your function is called inside fontification-functions, you will
> not have to monitor Emacs sources, your code will use a single tag, namely
> 'fontification-functions.

So, I will be able to unlock?

> > Wouldn't something like [...] not be much more robust?
>
> Definitely not.

Or not? I don't understand how these two answers from you combine.

It is impossible to correctly fontify log buffers if you are
restricted to semi-arbitrary parts of it: you need to at least see
where the current entry starts, even if it for whatever reason
includes a line with 100 K characters.

> It isn't for me personally, no.  It is important for Emacs users.

How about letting Emacs users decide for themselves? Let Logview
behave against your recommendations. And then, when the users discover
how crappy and unresponsive it is, as a result, compared to everything
else, they will just uninstall the package and use something better.

Paul

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

>
> >
> > I see that manually evaluating `(setq-local long-line-threshold nil)' in
> > a buffer where the optimization is already in effect (i.e. where
> > `(long-line-optimizations-p)' evaluates to t) doesn't disable the
> > optimization. Do you have a solution for that?
> >
>
> No, and that will not be supported.
>
> >
> > Depending on the mode being activated before Emacs decides to enable the
> > optimization (e.g. because one of the first lines is very long, I don't
> > know how exactly this is determined) seems very shaky.
> >
>
> Indeed.  As I told you the proper fix is not to disable these
> optimizations, but to adapt the code to handle locked narrowing, by
> explicitly unlocking the locked narrowing when, and only when, it needs to
> access a larger portion of the buffer.
>
> >
> > I briefly looked at the branch `feature/improved-narrowed-locking' and
> > saw that locking grew "tags". This probably implies that this is going
> > to be used more in the future, maybe already in Emacs 29.1. Is there
> > going to be some way to disable each and every new tag? Should I monitor
> > Emacs sources for new cases of narrowed locking with a tag previously
> > not used?
> >
>
> No, if your function is called inside fontification-functions, you will
> not have to monitor Emacs sources, your code will use a single tag, namely
> 'fontification-functions.
>
> >
> > What if one day this becomes available to Elisp and a submode that
> > decides to narrow-lock for whatever reason?
> >
>
> Don't worry, that won't happen.
>
> >
> > Wouldn't something like
> >
> > (let ((disable-locked-narrowing-yes-i-know-this-is-bad-but-still t))
> >    (widen)
> >    ...
> > )
> >
> > not be much more robust?
> >
>
> Definitely not.  It is more important to take measures to ensure that
> Emacs remains responsive for its users than to minimize the effort of
> Elisp programmers.

[-- Attachment #2: Type: text/html, Size: 3641 bytes --]