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 17:37:59 +0200 Message-ID: References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000066a22105e8b90837" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17894"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , 57804@debbugs.gnu.org To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 15 17:39:40 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 1oYqxo-0004Te-7Y for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Sep 2022 17:39:40 +0200 Original-Received: from localhost ([::1]:42508 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oYqxn-0000XH-5G for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Sep 2022 11:39:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38872) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYqxE-0000Uf-GN for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 11:39:07 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42030) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oYqxC-00073I-Fn for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 11:39:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oYqxC-0005Yc-8h for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 11:39: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 15:39: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.166325630021307 (code B ref 57804); Thu, 15 Sep 2022 15:39:02 +0000 Original-Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 15:38:20 +0000 Original-Received: from localhost ([127.0.0.1]:58962 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYqwV-0005Xa-Ve for submit@debbugs.gnu.org; Thu, 15 Sep 2022 11:38:20 -0400 Original-Received: from mail-ed1-f48.google.com ([209.85.208.48]:46766) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYqwS-0005XL-Tn for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 11:38:19 -0400 Original-Received: by mail-ed1-f48.google.com with SMTP id z13so13548129edb.13 for <57804@debbugs.gnu.org>; Thu, 15 Sep 2022 08:38:16 -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=v3H4w5/vU2Yf1viCim1zGTJ7CWUN/8g0c33mB6OBkdo=; b=hjwG+gXk/rm4sVuf/a2pfK6f7dnFSFP68cLHsaWJl1A9jI6uN8kl8UAe0/2fOwfudX NOdxa8jEuPihM7BwhPTrSG5NYcrVTHZINYuCTbigmsa0ODA2kS5W47HeObt1vBbQKa2B PANCiTc6kCVlMMQ4FwCvmzGM4fSoLiP6hjThh0U91C2xpnoaFDo0ymHuy9+YE95rXNX6 x0nGCV0UNJPQL3ZduwhIrnFBVEWV/4lNoAWuD9ZTcvbaQXtD2utPaAfb5yT80BN2zDhG v3/3J2SwMbaIbpbZ64B0xaSvOeIUbc+r8EGgONMaeH/zbmcOr7MUu0AKXkYQef3I6Jm1 f9Ig== 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=v3H4w5/vU2Yf1viCim1zGTJ7CWUN/8g0c33mB6OBkdo=; b=P3CZyOv7AKuUeNHuX5YLQscLnu60uXYZZv5yfZ7GGMxbFQNjnj23pOFifbU9EEo64I eSKkFMt+fxm7USh7cSNBzX9YQ3sOlmlcKYAry9c1qip2ZoypyxBc/0Drx3roUgxKDTrC a7H0tQtHRKgMRBVRWss66OMrcuDE/04Gpg6R1yepfQ5bmgQ7KZaDK1LUQfnIWhwvN9IU s9cfbX06prZmty+EIoIsZsARODy8IoggCM68RHW61M5U7mUm0G83AM3Tee1ylBLrOs6r Pwe65nQb79+pG6JGuUKfpG6ix8Rn0qW4pLLVO+PBSuoQtSKrJj0HdZLbmLAJ9sTVFCrD BaEw== X-Gm-Message-State: ACrzQf1cmXHuCtziO/WpAM3SSezmU/b6wJrJis4Wjvg80aF3MBjjVXxq u74JI90qFfkbV6ar0bk/mgVmuVOWAUpK3wN17g== X-Google-Smtp-Source: AMsMyM4hAHC67V2Z8VfD0Z3nUWUgRiYnjTx1mBVMQWaH1ohpifxBQ/OcvHqYYOj0WOCl3XtlBAxvNQh6yj/K9SPfnJo= X-Received: by 2002:a05:6402:43cf:b0:450:eae1:c9d3 with SMTP id p15-20020a05640243cf00b00450eae1c9d3mr365750edc.231.1663256291089; Thu, 15 Sep 2022 08:38:11 -0700 (PDT) In-Reply-To: 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:242602 Archived-At: --00000000000066a22105e8b90837 Content-Type: text/plain; charset="UTF-8" > > or is it "you have to rewrite, because we have decided so"? > > That's not how I would present things, no. It doesn't matter how you would present it, it's the result that matters. > Why does Logview infloop when > locked narrowing is in effect? This might be a bug in Logview Because it assumes that after `widen' all restrictions are gone. If I do x = 10 + 20 if (x == 25) throw new Error (); and this results in an error, then the bug is not _in my code_. If I need to treat every function as "pretty please, do this, but if you don't, it's fine, I'll do something else", my code will inflate tenfolds and will still not achieve its goals. > fontification-functions / jit-lock-function is not supposed to access and > modify a large portion of the buffer. "Is not supposed" is not the same as "must not do, else everything crashes". > I don't use Logview, and you did > not give a detailed recipe to reproduce the issue Recipe is obvious: (widen) (if (/= (point-min) 1) (error "WTF is going on?")) Why Logview needs to access the full buffer at any time? Because it operates lazily. It expects that log files are several megabytes and therefore doesn't parse them fully. There are at least two passes: first splits the file into entries, second fontifies. The first can be used for other reasons too. In other words, when fontification comes around, the relevant buffer part may not be even split into entries yet, so fontification code calls the splitting code first. Logview also almost never moves the point internally (because that might be slow in huge buffers), instead it needs to be able to query text properties anywhere. And with narrowing this is impossible. Frankly, I don't see why I need to tell you _why_ I need this. Even if I write five pages explaining every single detail, all things I have considered in the years this mode had been written (with one major refactoring for performance reason), I know the answer: "Yeah, but you could do X or Y instead". Of course, I have never thought about that, yeah. Of course I have just chosen this approach randomly. You either accept that there _might_ be something you haven't thought about, you have never discovered or simply never needed. Or you don't. Then you just say: "Do it this way! For me it's enough, therefore it _must_ be enough for everyone. Or if it's not it's their problem and I don't care.". Paul On Thu, 15 Sept 2022 at 17:10, Gregory Heytings wrote: > > > > > Is it technically impossible to lift narrowing restrictions in Emacs 29 > > > > It is not, you can choose a radical approach and long-line-threshold to > nil. Or you can choose a less radical approach and set > long-line-threshold to a larger value (as I already told you twice IIRC). > > > > > (as in, something would break), > > > > Locked narrowing is one part of the solution to the long lines bug in > Emacs, so something could indeed break if you turn that solution off. > > > > > or is it "you have to rewrite, because we have decided so"? > > > > That's not how I would present things, no. Why does Logview infloop when > locked narrowing is in effect? This might be a bug in Logview: > fontification-functions / jit-lock-function is not supposed to access and > modify a large portion of the buffer. I don't use Logview, and you did > not give a detailed recipe to reproduce the issue, so it's difficult to > give more precise advice. > --00000000000066a22105e8b90837 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> > or is it "you have to rewrite, because we h= ave decided so"?
>
> That's not how I would present t= hings, no.

It doesn't matter how you would present it, it's = the result that
matters.

> Why does Logview infloop when
&g= t; locked narrowing is in effect?=C2=A0 This might be a bug in Logview
<= br>Because it assumes that after `widen' all restrictions are gone.=C2= =A0 If I
do

=C2=A0 =C2=A0 x =3D 10 + 20
=C2=A0 =C2=A0 if (x = =3D=3D 25)
=C2=A0 =C2=A0 =C2=A0 throw new Error ();

and this resu= lts in an error, then the bug is not _in my code_.

If I need to trea= t every function as "pretty please, do this, but if
you don't, = it's fine, I'll do something else", my code will inflate
te= nfolds and will still not achieve its goals.

> fontification-func= tions / jit-lock-function is not supposed to access and
> modify a la= rge portion of the buffer.

"Is not supposed" is not the sa= me as "must not do, else everything
crashes".

> I do= n't use Logview, and you did
> not give a detailed recipe to repr= oduce the issue

Recipe is obvious:

=C2=A0 =C2=A0 (widen)
= =C2=A0 =C2=A0 (if (/=3D (point-min) 1) (error "WTF is going on?")= )

Why Logview needs to access the full buffer at any time? Because i= t
operates lazily. It expects that log files are several megabytes andtherefore doesn't parse them fully. There are at least two passes:first splits the file into entries, second fontifies. The first can be
= used for other reasons too. In other words, when fontification comes
aro= und, the relevant buffer part may not be even split into entries
yet, so= fontification code calls the splitting code first. Logview
also almost = never moves the point internally (because that might be
slow in huge buf= fers), instead it needs to be able to query text
properties anywhere. An= d with narrowing this is impossible.

Frankly, I don't see why I = need to tell you _why_ I need this. Even if
I write five pages explainin= g every single detail, all things I have
considered in the years this mo= de had been written (with one major
refactoring for performance reason),= I know the answer: "Yeah, but you
could do X or Y instead". O= f course, I have never thought about that,
yeah. Of course I have just c= hosen this approach randomly.

You either accept that there _might_ b= e something you haven't thought
about, you have never discovered or = simply never needed. Or you
don't. Then you just say: "Do it th= is way! For me it's enough,
therefore it _must_ be enough for everyo= ne. Or if it's not it's their
problem and I don't care."= ;.

Paul

On Thu, 15 Sept 2022 at 17:10, Gregory Heytings <gregory@heytings.org> wrote:
<= /div>

>
> Is it technically impossible to lift narrowing restrictions in Emacs 2= 9
>

It is not, you can choose a radical approach and long-line-threshold to nil.=C2=A0 Or you can choose a less radical approach and set
long-line-threshold to a larger value (as I already told you twice IIRC).
>
> (as in, something would break),
>

Locked narrowing is one part of the solution to the long lines bug in
Emacs, so something could indeed break if you turn that solution off.

>
> or is it "you have to rewrite, because we have decided so"?<= br> >

That's not how I would present things, no.=C2=A0 Why does Logview inflo= op when
locked narrowing is in effect?=C2=A0 This might be a bug in Logview:
fontification-functions / jit-lock-function is not supposed to access and <= br> modify a large portion of the buffer.=C2=A0 I don't use Logview, and yo= u did
not give a detailed recipe to reproduce the issue, so it's difficult to=
give more precise advice.
--00000000000066a22105e8b90837--