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

Previous Next

Full log

Message #105 received at 57804 <at> debbugs.gnu.org (full text, mbox):

From: Paul Pogonyshev <pogonyshev <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gregory Heytings <gregory <at> heytings.org>, 57804 <at> debbugs.gnu.org,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#57804: An infinite loop in a `fontify-region' function causes
 Emacs to hang indefinitely
Date: Thu, 15 Sep 2022 21:36:27 +0200

[Message part 1 (text/plain, inline)]

> What do you mean by ":workaround"?

In this case something that can be done for me personally, but
not in the mode itself.

> Every variable can be given a local value by using setq-local.  Did
> you try that?

No. Tried now, it works.

Several questions though.

* 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? 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. Also, what if someone
opens file `my-log-with-funny-extension.records' and then manually
activates Logview mode?

* 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?

* Wouldn't something like

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

not be much more robust?

Paul

On Thu, 15 Sept 2022 at 21:16, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 57804 <at> debbugs.gnu.org
> > From: Paul Pogonyshev <pogonyshev <at> gmail.com>
> > Date: Thu, 15 Sep 2022 20:49:17 +0200
> >
> > > 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.
>
> What do you mean by ":workaround"?  Doing that disables the feature
> which you don't want, so it fits the definition of "solution" in my
> book.
>
> > The variable is not buffer-local, so I cannot change it
> > in the mode, only as my personal setting.
>
> Every variable can be given a local value by using setq-local.  Did
> you try that?  If you did, and it didn't work, please show a recipe to
> reproduce this problem.
>

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.