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 22:40:24 +0200 Message-ID: References: <87pmfx6h7y.fsf@gnus.org> <2b58b8f5429a6e3aecda@heytings.org> <834jx85tyv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000f73b2705e8bd4180" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29773"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 57804@debbugs.gnu.org, Lars Ingebrigtsen To: Gregory Heytings Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 15 22:41:13 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 1oYvfc-0007YP-2h for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Sep 2022 22:41:12 +0200 Original-Received: from localhost ([::1]:44606 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oYvfb-000146-61 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 15 Sep 2022 16:41:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45238) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYvfS-00013q-GA for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 16:41:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42419) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oYvfS-0008Qx-7R for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 16:41:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oYvfS-0004zF-2k for bug-gnu-emacs@gnu.org; Thu, 15 Sep 2022 16:41: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 20:41: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.166327444519134 (code B ref 57804); Thu, 15 Sep 2022 20:41:02 +0000 Original-Received: (at 57804) by debbugs.gnu.org; 15 Sep 2022 20:40:45 +0000 Original-Received: from localhost ([127.0.0.1]:59351 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYvfA-0004yY-Dq for submit@debbugs.gnu.org; Thu, 15 Sep 2022 16:40:45 -0400 Original-Received: from mail-ed1-f50.google.com ([209.85.208.50]:44601) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYvf8-0004yK-JL for 57804@debbugs.gnu.org; Thu, 15 Sep 2022 16:40:43 -0400 Original-Received: by mail-ed1-f50.google.com with SMTP id x94so11406279ede.11 for <57804@debbugs.gnu.org>; Thu, 15 Sep 2022 13:40:42 -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=ZCVdpD6E3VSOevOCEVsWLRz1FaaRTUuhFu4ZQOAMnlo=; b=oemct0n6VBFHrhLxcwJaenBzXpJex1PLb5YoJ4t3xiyUgV76mJpPBJPXeyKyqsTVVQ tQNVz1RhG+4hLNJNi/BTSPapRYqlfi0QkAnQHYAg4M5MYwxFsZAnZUuBVPDR2VQkK00q sSVegF2HxLD8XRnYRuPTDKtCCVkqZW5hkpBRPCzJcoPdaZg76l16bUKg2HMcvpEdG2oQ EnBI7IHpUXpG2dc4BUyVYbu9S9yyydf5xF2gF7kCaSAx0quWx3qrpH3HXVp7ckJb2gV5 OSTNqtnFshXmg9FP2/+WTjztIO2JbzirKg2O0mPGwaX/Pkltp/Kfvp+UqZA+m8Q1xckn 92IQ== 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=ZCVdpD6E3VSOevOCEVsWLRz1FaaRTUuhFu4ZQOAMnlo=; b=55JGs/Ejz84M02DfZDID4rrikCf33UdeYhqS0s5FUidsBtCHh7ZPaxbnKD+McqKuIW 7mrKIuFPP6uXVRRRZHB34QLHzlM11VujMQEaK1SZ1lsJ4PFiDwqHnEaBPcrguxuQKjjv XznwnoYSaO6JAxi6WAyWUtxJ0iq04zCKnEKwis/QKWiNXUqBrcgv/mrTHz1/mYHfmZb3 qINItzrg5mUqMByy7YfVHZKzt+d+4+Ykc9hnJh3NkTkPhHZyw1BR8qFZi5QJeUEU+kY4 MR+IHoErdYTIhHmXsjFSx3PvXgcQGIocGp4Ypx9/IX8weOnSAiDSRw9yAdqxt4bkVMuA Qiew== X-Gm-Message-State: ACrzQf3Z7rfhzOrNGkJyKkEBs23gHPlc0XsOQ4NOJal3LvSu6ipcRzR3 iEkBIPa8/o2P9enD+GwfOVseXIHSoOiIHMCLgg== X-Google-Smtp-Source: AMsMyM50UxZtURmx5D9TX5EKOQMZcxY5i8qLMlfGgotFUARf79fmF5pnxHMI101L4vxIXgxrlGBygMxUONYU51oa1TI= X-Received: by 2002:a05:6402:3904:b0:451:f01c:9217 with SMTP id fe4-20020a056402390400b00451f01c9217mr1365765edb.78.1663274436736; Thu, 15 Sep 2022 13:40:36 -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:242649 Archived-At: --000000000000f73b2705e8bd4180 Content-Type: text/plain; charset="UTF-8" > 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 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. --000000000000f73b2705e8bd4180 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> No, if your function is called inside fontification-f= unctions, you will
> not have to monitor Emacs sources, your code wil= l 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 se= mi-arbitrary parts of it: you need to at least see
where the current ent= ry starts, even if it for whatever reason
includes a line with 100 K cha= racters.

> It isn't for me personally, no.=C2=A0 It is import= ant for Emacs users.

How about letting Emacs users decide for themse= lves? Let Logview
behave against your recommendations. And then, when th= e users discover
how crappy and unresponsive it is, as a result, compare= d to everything
else, they will just uninstall the package and use somet= hing better.

Paul

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

>
> I see that manually evaluating `(setq-local long-line-threshold nil)&#= 39; 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 t= he
> optimization (e.g. because one of the first lines is very long, I don&= #39;t
> know how exactly this is determined) seems very shaky.
>

Indeed.=C2=A0 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 thi= s is going
> to be used more in the future, maybe already in Emacs 29.1. Is there <= br> > going to be some way to disable each and every new tag? Should I monit= or
> 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)) >=C2=A0 =C2=A0 (widen)
>=C2=A0 =C2=A0 ...
> )
>
> not be much more robust?
>

Definitely not.=C2=A0 It is more important to take measures to ensure that =
Emacs remains responsive for its users than to minimize the effort of
Elisp programmers.
--000000000000f73b2705e8bd4180--