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

[Eli Zaretskii]

> From: Paul Pogonyshev <pogonyshev@gmail.com>
> Date: Thu, 15 Sep 2022 21:36:27 +0200
> Cc: Gregory Heytings <gregory@heytings.org>, Lars Ingebrigtsen 
> <larsi@gnus.org>, 57804@debbugs.gnu.org
> 
> * 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?

Not at present, I believe (but Gregory may know better).  I don't
think we saw a need for that, yet.

> Depending on the
> mode being activated before Emacs decides to enable the optimization
> (e.g. because on of the first lines is very long, I don't know how
> exactly this is determined) seems very shaky.

I think you can rely on this: the decision is made the first time the
buffer is displayed, which is after the mode is turned on in it.

Of course, the danger is that if the file really has very long lines,
Emacs might become unusable.  That's what this feature is about:
making Emacs usable when editing files with very long lines.

> Also, what if someone
> opens file `my-log-with-funny-extension.records' and then manually
> activates Logview mode?

No solution for now.

> * 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? What if one day this becomes available to Elisp
> and a submode that decides to narrow-lock for whatever reason?  How
> could I prevent that?

I'll leave it for Gregory to answer, since I don't yet know his plans
for that branch.