From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Pogonyshev Newsgroups: gmane.emacs.bugs Subject: 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-ID: References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000003d936205e8bc5d9b" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2477"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Gregory Heytings , 57804@debbugs.gnu.org, Lars Ingebrigtsen To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 15 21:37:11 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oYufe-0000Rl-Hp for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Sep 2022 21:37:10 +0200 Original-Received: from localhost ([::1]:51866 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oYufd-00022X-L1 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Sep 2022 15:37:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58660) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYufX-00021k-0T for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 15:37:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42272) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oYufW-0004In-In for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 15:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oYufW-0003Hu-E5 for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 15:37:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Paul Pogonyshev Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 15 Sep 2022 19:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57804 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix Original-Received: via spool by 57804-submit@debbugs.gnu.org id=B57804.166327060812611 (code B ref 57804); Thu, 15 Sep 2022 19:37:02 +0000 Original-Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 19:36:48 +0000 Original-Received: from localhost ([127.0.0.1]:59204 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYufH-0003HL-Ai for submit@debbugs.gnu.org; Thu, 15 Sep 2022 15:36:47 -0400 Original-Received: from mail-ed1-f52.google.com ([209.85.208.52]:36615) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYufF-0003H5-9X for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 15:36:46 -0400 Original-Received: by mail-ed1-f52.google.com with SMTP id e18so28483405edj.3 for <57804@debbugs.gnu.org>; Thu, 15 Sep 2022 12:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=+HaWSjb4ZUTLp3vG9qqtYK9gllbn9L2ZBnzj5TIVurA=; b=T1D7uDk3vjEmmKkiGo4vBSMAII9dBvpU1gOPn16xiHZb+DJBI6O3hr8AiWExh1Cl3n bfwmgu1hE9Wsenym7ZDYu4Ra7xJYpwRubNOE7iXOKhInkc/aygTbYLIdVhxmT2j4xE+u WPtawVGl4htZU7wxIw2DGyadloouFZe4u+FEZ0HGljdU7XteB2RSQf8XWmrDL1zQf3mx LylkiJp7uF+PjQ0sXDc/ADxxF2bBk3aUqQK8xwDWdayDyqfvH4F+4DZ/o70RPMgN9cw0 YeOraPP7tI+U40+yldZ7duqhe9ZYO/HJVqmD6rBrZfnaLt+6npqNM4nEPSJGf3/eKgJe ox3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=+HaWSjb4ZUTLp3vG9qqtYK9gllbn9L2ZBnzj5TIVurA=; b=SdYc35gl5QUQxDyIPi3Xw46UfIPonisfu0wW+y+ZkXfETrNRNsSLGdpgzW32uFYCas k+4L6Cjk7JYZa9tp3jthLP1T5azYur50qn2yyrFCGgM+dThT9fPj7vOJEI5AAdHroSex Q8N/q5dRRq9k7Mz2nvrPi3J82bFc68dA9jXrn7Ssy1LxESXXyxds0JnQK6YGUtrbKJnZ xsjdbusH2gwdRcKsPrl4KzJ6Z6pPrSVnFWuTxxuvMtkpP5wNDdSbXIU+PK3irDxDDPD1 DfRLR1U+arfIP8b7zr171CbkffcO1gYy5VLYbbwK1llCx6D529Qb5CN9JZCKtwZY6Olu knag== X-Gm-Message-State: ACrzQf0Z97/JbRzsSwUyrDPh67OqHzYA7kwF1kV2UyWTY5MUR3EErcXc evSe1R5uJg7dKd0ylZfF4Tawfszr5XoZe5rs6w== X-Google-Smtp-Source: AMsMyM4OSGWYobQ/PfqjupnCdoqFQigbVbCi0xZ17eQNBanzXg9AfoX9HmZ+ItHN0fHcW7J4qdXloTkUDuxyKEqdFJg= X-Received: by 2002:a05:6402:516f:b0:44e:9151:d54b with SMTP id d15-20020a056402516f00b0044e9151d54bmr1159640ede.241.1663270599364; Thu, 15 Sep 2022 12:36:39 -0700 (PDT) In-Reply-To: <834jx85tyv.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:242639 Archived-At: --0000000000003d936205e8bc5d9b Content-Type: text/plain; charset="UTF-8" > 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 wrote: > > Cc: Lars Ingebrigtsen , 57804@debbugs.gnu.org > > From: Paul Pogonyshev > > 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. > --0000000000003d936205e8bc5d9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> What do you mean by ":workaround"?=C2=A0

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

> Ev= ery variable can be given a local value by using setq-local.=C2=A0 Did
&= gt; you try that?

No. Tried now, it works.

Several questions though.

* I see that manuall= y evaluating `(setq-local long-line-threshold
nil)' in a buffer wher= e the optimization is already in effect (i.e.
where `(long-line-optimiza= tions-p)' evaluates to t) doesn't disable
the optimization. Do y= ou have a solution for that? Depending on the
mode being activated befor= e 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) se= ems very shaky. Also, what if someone
opens file `my-log-with-funny-exte= nsion.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. Isthere 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
previ= ously not used? What if one day this becomes available to Elisp
and a su= bmode that decides to narrow-lock for whatever reason?=C2=A0 How
could I= prevent that?

* Wouldn't something like

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

not be much more robust?

Paul

On Thu, 15 Sept 2022 at 21:16, Eli Zaretskii <eliz@gnu.org> wrote:
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 57804@debbugs.gnu.org
> From: Paul Pogonyshev <pogonyshev@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=C2=A0 `(setf long-line-threshold nil)' to Emacs st= artup configuration
> file a couple of days before. But unless I'm missing something, th= is is not a
> fix, only a workaround.

What do you mean by ":workaround"?=C2=A0 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.=C2=A0 Did you try that?=C2=A0 If you did, and it didn't work, please show a recip= e to
reproduce this problem.
--0000000000003d936205e8bc5d9b--