From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 08 15:37:26 2022 Received: (at submit) by debbugs.gnu.org; 8 Sep 2022 19:37:26 +0000 Received: from localhost ([127.0.0.1]:60116 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oWNL3-0004Ca-PZ for submit@debbugs.gnu.org; Thu, 08 Sep 2022 15:37:26 -0400 Received: from lists.gnu.org ([209.51.188.17]:39264) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oWNKy-0004CP-Ss for submit@debbugs.gnu.org; Thu, 08 Sep 2022 15:37:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56186) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oWNKy-0001sa-Fc for bug-gnu-emacs@gnu.org; Thu, 08 Sep 2022 15:37:20 -0400 Received: from mail-ej1-x62d.google.com ([2a00:1450:4864:20::62d]:45947) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oWNKv-0006Tc-AS for bug-gnu-emacs@gnu.org; Thu, 08 Sep 2022 15:37:19 -0400 Received: by mail-ej1-x62d.google.com with SMTP id dv25so11158278ejb.12 for ; Thu, 08 Sep 2022 12:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date; bh=sIjQHTOugGWFmFTLIslg+PxqZ1ATasqPLMX2wk+4Tk4=; b=m+5Xvc1bAhsqT9Ow8OTAnHoeKRdf3Ii8vT071euOWZAFbodkIMBGN+AnRTKUzwk2wo BzLCmJ8Yv5rN9261Pb5sRHnPrIO/ZVlw/Rgjt0N5XPfcgPjBbNRQIr321irrc+1p57be OonZW7s6qAYEsMkDDAfTbrpgXjITscjowq5UEyej5mve9aaR/WL5JyxZBe2UB775VZLf ivNT4jftaxLc4li5zCqnl/fnz894WFXxGztc287Z9uiiBtle3eBLifHrpHXc+MQl4Ul2 c5TJiAWRrYPzXiTSSIvQ5aGBfvFqRxfMBMgkmzPkAhRBjhRnktueLhtM/QdSlXJHAm98 RKCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date; bh=sIjQHTOugGWFmFTLIslg+PxqZ1ATasqPLMX2wk+4Tk4=; b=S67qCpB3pnJSw5XnLyPcLMSnwo/Aidtqt8oUu/2QlNhJNgOd5VFrhAJPrLsh5F9MBV wz5hWEZUL5OEvcLTf1IQMvRHZi4k3HkxlsbdL4AHtO25A3s8bQymuDE+X405TdeNEull fp8jEwwBSke73Is6wGzCll59bLamSBRySsCYH3ix6w609JgqDsuiEnPqWKlkyxjqAs0g 0PBIQkssoSXaZlBZzqqtGFouc92/2FtM4/aJcEjDocgGJzocd3FYoXTicIzvDNCzOjw1 XnZoTO2Ke+V+SMToVlk+wtMX81rO5mT+0uqEKj0i4XO+LgFWjA7eOigLJ39z5FrCfVtf awaQ== X-Gm-Message-State: ACgBeo2mu1fZPEDyZY51qnIy8cjG0Lf5e1jh7hvUjKvUUzsGm4cIEA/a a+06GCDd0oWxFWppDpAECgfxSk3HoJVl6mVevyq472V94w== X-Google-Smtp-Source: AA6agR45DTLeqIq5+Nvo0TMCF2gpvauEr8C0mUT30iZ9dmBLz0rpltBofUaMmD4ukTQRls7DfawDAybCaWhZDu4wYYM= X-Received: by 2002:a17:906:d54c:b0:750:5e1c:b88c with SMTP id cr12-20020a170906d54c00b007505e1cb88cmr7353093ejc.485.1662665833829; Thu, 08 Sep 2022 12:37:13 -0700 (PDT) MIME-Version: 1.0 From: Paul Pogonyshev Date: Thu, 8 Sep 2022 21:37:02 +0200 Message-ID: Subject: locked narrowing breaks existing code without an apparent way to repair To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="00000000000067da2b05e82f8e52" Received-SPF: pass client-ip=2a00:1450:4864:20::62d; envelope-from=pogonyshev@gmail.com; helo=mail-ej1-x62d.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --00000000000067da2b05e82f8e52 Content-Type: text/plain; charset="UTF-8" "Locked narrowing" added in Emacs 29 cannot be (temporarily) canceled by code called inside. This in particular breaks Logview ( https://github.com/doublep/logview), because this narrowing is in effect during fontification and causes Logview to fall down into an infinite loop. Moreover, variable `restrictions-locked' appears to be not exposed to Elisp, meaning that this cannot be cleared even with an explicit let-bind. The mode simply cannot work without an ability to temporarily widen the text. Macro `logview--std-temporarily-widening' is used 35 times in its code: (defmacro logview--std-temporarily-widening (&rest body) (declare (indent 0) (debug t)) `(save-restriction (let ((logview--point-min (logview--point-min)) (logview--point-max (logview--point-max))) (widen) ,@body))) To make it even harder to debug, Emacs sometimes hangs completely with even C-g not aborting faulty code (in this case "faulty" because of incompatible changes in Emacs itself). Paul --00000000000067da2b05e82f8e52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"Locked narrowing" added in Emacs 29 cannot be (= temporarily) canceled by code called inside. This in particular breaks Logv= iew (https://github.com/doub= lep/logview), because this narrowing is in effect during fontification = and causes Logview to fall down into an infinite loop. Moreover, variable `= restrictions-locked' appears to be not exposed to Elisp, meaning that t= his cannot be cleared even with an explicit let-bind.

Th= e mode simply cannot work without an ability to temporarily widen the text.= Macro `logview--std-temporarily-widening' is used 35 times in its code= :

(defmacro logview--std-temporarily-widening (&am= p;rest body)
=C2=A0 (declare (indent 0) (debug t))
=C2=A0 `(save-rest= riction
=C2=A0 =C2=A0 =C2=A0(let ((logview--point-min (logview--point-mi= n))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(logview--point-max (logvie= w--point-max)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0(widen)
=C2=A0 =C2=A0 =C2= =A0 =C2=A0,@body)))

To make it even harder to = debug, Emacs sometimes hangs completely with even C-g not aborting faulty c= ode (in this case "faulty" because of incompatible changes in Ema= cs itself).

Paul
--00000000000067da2b05e82f8e52-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 08 15:57:17 2022 Received: (at 57684) by debbugs.gnu.org; 8 Sep 2022 19:57:17 +0000 Received: from localhost ([127.0.0.1]:60161 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oWNeH-0004lu-6P for submit@debbugs.gnu.org; Thu, 08 Sep 2022 15:57:17 -0400 Received: from heytings.org ([95.142.160.155]:60956) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oWNeF-0004lk-2L for 57684@debbugs.gnu.org; Thu, 08 Sep 2022 15:57:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1662667033; bh=298/Wcy6qtX/l6PPi/E08DbVy6m7wBq6B1KOOuK+uGQ=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=cySMAbZ8YBtd3ySK2qDgBpYSY7D50rjX7pP6f7Ui3YygWBPyyGPdBwIX6EynKMusa XVVwOHRuwNMjGBLA5kI9Sngo55mnLcrp9NQuwRHlrmOMMulRZqpiv9SukzPXtvApX6 E/y0typhNyEGp92zcEmLWe+YYtflyj9+3OicS6UssGMAigWTe8NJkyf+5D8glg5LLb v3v+i6keBvkTfBpeFoDdibJsjRAoQY/HxX4wSvbj8xYKnuwf5Z0ACODI+WJ0v3WUlb NJqgd6ezuj8AFyuSNU4+q/7UJdF6gEEVjQaVOB+rsOtGDt+I6l9PmlP/PadyKFIGmT fO47z3seiW87g== Date: Thu, 08 Sep 2022 19:57:13 +0000 From: Gregory Heytings To: Paul Pogonyshev Subject: Re: bug#57684: locked narrowing breaks existing code without an apparent way to repair In-Reply-To: Message-ID: <2e25ca87e3c6ebb795d7@heytings.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57684 Cc: 57684@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > "Locked narrowing" added in Emacs 29 cannot be (temporarily) canceled by > code called inside. > This issue is being worked on, see the (not yet finished) feature/improved-locked-narrowing branch. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 08 16:31:11 2022 Received: (at 57684) by debbugs.gnu.org; 8 Sep 2022 20:31:11 +0000 Received: from localhost ([127.0.0.1]:60226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oWOB5-0005gL-3V for submit@debbugs.gnu.org; Thu, 08 Sep 2022 16:31:11 -0400 Received: from mail-ej1-f44.google.com ([209.85.218.44]:42532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oWOAx-0005fk-C6 for 57684@debbugs.gnu.org; Thu, 08 Sep 2022 16:31:10 -0400 Received: by mail-ej1-f44.google.com with SMTP id r17so13378163ejy.9 for <57684@debbugs.gnu.org>; Thu, 08 Sep 2022 13:31:03 -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=453EV6+Vk4UiA+QPML9PMd8FW+X3vUlRpn0D8jE/Fgo=; b=FSWujGN5KQQ7lyf+3e8YCEZmB7NYo+Uq5kv0fj5eZM9ZeAYkFTLpte7vtEGV9D0H9e JJN7SnbvSC4SkeAVHQ9R/bpqHvyjFfaxU2RG8JXZC26b42E32W1Af5gRWTG/b+ifuNrs rugPMk+lP3sKgIMoCX5Z3zHz1p34z4SC0C+wZME97xUsCGgWdE/tX5+GMjRrGU6AJnVv uKEzxhKBGsYF88DmygTpqmbQxriq3RW9h6TdV3UYQnXrRRYOPiY/cdZ5V/0QXqusHtIJ ynJuRGDaZlrfbBXst6yur84bg9eP595x9biO7SrTiLba6qkCZUKJqYpIkQ2vQkVJrY7R WTfw== 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=453EV6+Vk4UiA+QPML9PMd8FW+X3vUlRpn0D8jE/Fgo=; b=k/JFootsMQ/0Kpugq7sCruhveDFLLLYKgE74IbEnDZCkGy5rsyam0IBYx875132xKM 7RzBoY7H8Cg/KSs4NgMdIeBGSC1qw5AWknSCHR1Bi1Lyo7oncG2jle0JRF77PKb9rUtX ftUYU4fQmVgzWEzX3gm4MwUJTR0IqhmZQaI16iytd1iB7mGK/q/HUX3sCV2vB/QHZjUD Cm73bLirVMb3GxDwvlnzXgXroxbCnN688e5/HpYfbAl3j/z9cn6jW7LWRKHQn8r19cK4 EJu+p+yTqg0vfyzQAGmZnfxkcg14gzKMNv78NwYXIwozJsgf0q7vHufkrdSx6lF/CF5L Vemg== X-Gm-Message-State: ACgBeo2/22tnJ1EKNuv4+BQxxfqhc6WNc7+gv94y5PH3NGleXD9pTvMD iJdXSRO9+JKyBEB9AzpckxmpvEfGC+nQLe7BGHabP5g= X-Google-Smtp-Source: AA6agR7tfUg+Kd0H5LSYnHQimuQZkixdgr5ZQLXLZs3DX9y9WHjwNdx1tzVmDcJHpoDVMuD3/nNoiufbRyvjgV/UQwk= X-Received: by 2002:a17:906:d54c:b0:750:5e1c:b88c with SMTP id cr12-20020a170906d54c00b007505e1cb88cmr7495250ejc.485.1662669057310; Thu, 08 Sep 2022 13:30:57 -0700 (PDT) MIME-Version: 1.0 References: <2e25ca87e3c6ebb795d7@heytings.org> In-Reply-To: <2e25ca87e3c6ebb795d7@heytings.org> From: Paul Pogonyshev Date: Thu, 8 Sep 2022 22:30:45 +0200 Message-ID: Subject: Re: bug#57684: locked narrowing breaks existing code without an apparent way to repair To: Gregory Heytings Content-Type: multipart/alternative; boundary="0000000000008a42c805e8304e66" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57684 Cc: 57684@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000008a42c805e8304e66 Content-Type: text/plain; charset="UTF-8" Good to hear. I think in all cases it should be left to the coder to temporarily lift restrictions, even if those are "locked", maybe with strong warnings in documentation. Speed should always come a second priority to functionality. Besides, Logview (one example of what would suffer if widening is impossible) is very fast. As an example of why widening might be needed: fontification may depend on preceding text in the buffer. Maybe standard Emacs fontification code handles that separately, but e.g. Logview (almost) completely replaces the standard code here with a home-grown solution aimed specifically at log files. And actually this was done exactly for speed. Anyway, I hope this is finished soon. Paul On Thu, 8 Sept 2022 at 21:57, Gregory Heytings wrote: > > > > > "Locked narrowing" added in Emacs 29 cannot be (temporarily) canceled by > > code called inside. > > > > This issue is being worked on, see the (not yet finished) > feature/improved-locked-narrowing branch. > --0000000000008a42c805e8304e66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good to hear. I think in all cases it should be left to th= e coder to
temporarily lift restrictions, even if those are "locke= d", maybe
with strong warnings in documentation. Speed should alwa= ys
come a second priority to functionality. Besides, Logview (one=
example of what would suffer if widening is impossible) is very<= /div>
fast.

As an example of why widenin= g might be needed: fontification
may depend on preceding text in = the buffer. Maybe standard
Emacs fontification code handles that = separately, but e.g.
Logview (almost) completely replaces the= standard code here
with a home-grown solution aimed specifically= at log files. And
actually this was done exactly for speed.

Anyway, I hope this is finished soon.

Paul

On Thu, 8 Sept 2022 at 21:57, Gregory Heytings <gregory@heytings.org> wrote:
<= /div>

>
> "Locked narrowing" added in Emacs 29 cannot be (temporarily)= canceled by
> code called inside.
>

This issue is being worked on, see the (not yet finished)
feature/improved-locked-narrowing branch.
--0000000000008a42c805e8304e66-- From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 08 21:47:14 2022 Received: (at 57684) by debbugs.gnu.org; 9 Sep 2022 01:47:14 +0000 Received: from localhost ([127.0.0.1]:60546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oWT6q-00057h-Aj for submit@debbugs.gnu.org; Thu, 08 Sep 2022 21:47:14 -0400 Received: from sonic309-22.consmr.mail.ne1.yahoo.com ([66.163.184.148]:40175) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oWT6i-000578-VR for 57684@debbugs.gnu.org; Thu, 08 Sep 2022 21:47:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1662688014; bh=i/yVB8gSqTxhaq55vjbgh9GUjn/+wpBaGe+04chou7E=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=M5LUwWgE968i2y3jQ+jbb4nQYhoPt9JXrqMPxcpe92e3rlWy5lTeJdUMq9iHPx/D+8R0UQZqrrIYPsA56hZSgdKwwUQnxwfOQvaLXQZCL8mfne6mqq4UbZgePKuCbqzww/g71exflRehgciLtS+euXYnvxgnmQZaIYhXEWqw5B4cKFMb9pXHc0SHifdsdAfctwJyyV0D2AhYyQ53kdcl690st8ZTt3UxUg9RAYdn4iArsas8YS9I91gDyiC+9GTZm/7m4xMBfLs7qBp2iXu03NYs1v7HKIoJtpn5tPeEhVh++vGM0iYsSbTfIjC8Sl8Al+RJCAjiySSeF+O+QyGMFA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1662688014; bh=2zSimoZerbVQL56R2OY90eVZ2Rx/aNppD3UihfEfucS=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=XdOck63C4DTTgks7AwVAsulKlXQuhi4WfsDEydASC1rHp5L5Q2wpkjaGmbOZxmx9gLfcm4aaRzEUixV/SqgXJP6wKuf8UkySS2G/jw7StjKTChXpU8tCpuN5H+qpdObVFqaFE5DK45Qv8df7RRFqC06+Jt/cNab6SACnFzAhs9fLuTGMt4Uhp+ErnWLr5U+3UYG4JbnYpxl1IIgrTFpo1K5ISOjNtXzZR74JSL/P6MeF+hdhqozmrp+BH9aX284VO9cAr5t/if8L1N6AuDz+UhYpMgIXNu+zjAfieJY5pmZ8/ny2Zqbux/X8A5IBzJoT7gag9rqPp1OacPY9CH6RZw== X-YMail-OSG: raENvZsVM1k086kfQ5UF896BlKSW6qM60yJ7atElf4NLyCSXuEy4gTqlBNBSKEt g2mZ5wr9gvVDVKlltsyhCd9WRBVzFM.PIWyF7HK1ffz6DFFqDpZGkjyYLepmMmWMmwNn.wBZOE5Z L1NRJC3NUyudKl.tWY1AEVupUf2GDGmuEIc2r0hqIjdkR_0kmYmLnuISnrQ.W1EmMPSFo_tPXCzl Ohy6jie6u43Jc5s97jxKIYs7jS9DTK51b5Y6HVqfRQV_4cCTF5gS4qud3zohw3fjUGHd5TffN5f7 b77K8y3j56XkIjo6gmv21isNMeUuCOQqmc18IbpnVWmp2BExBDKspxWWZ8asI0E4RJ.syDDy76QF UnikULjn2H_1L0LqEqaKIzL5mwaURZZW6gqSuppx_nQeNuGEDawTFMIlveFPQ.Gzu_.sLAOxfDHQ 3qusA5xS59eAS7McnwKY5Am4ZooDD1MY6r0veJ7NEl47jOhLbyARP8sPXI6d3.TZ9bOBzZUo9VOW vnqVXxpn2n7ZkdYMvGllt8xfJQjsK7h1ma9cQKHTe5GnqPnqkT_91BEfwGYTBucNbxBeDSbzmyGt CV2G5bK80AaKOKijVrmKpVtosVjRx5xBXh2y.FzZi3j4BTLI1F4yLLQyFJa2r5SNbri00aJ.m8.o wCEGLNj4N97riVj3o448sZ.4Hb4b.o7VSFkyOPBa0unqHnYCSeYidpuc9L4DnWKGem1_pNQAAFTf o4kehVs503D3p9Vt46Mtl1KNhUP7v52isOD2rxNKMjaGGujLCtZUpdAmJYxhNwm_WY55akVTxn_4 uJR4xOxG.6elH5T2LD1jJdO4p9yER2Ccw4J4NsOOCVXc3bDgpJJ8gWSEvkdX2It3uXvJF4ONddip E4Jnwfq4IqJKl_80NptpqTZqT6.su93HipMgr5hmMxlYjKZzsd2oRNDIDh4ozwihwr6oXjrJho4_ s8pcj8EKzvq8YqdmaU5guM.6Gmwd2y4Hn.idi8ev9IxW.ovPHi7g02SK4zF.YsVdULaKMaj9wiEs _AcKQFaKTXVeAo6k1vBvWQN1IPhDGB_RHdEwmKouhQ3cTNR9uoUUnGkTw2lYpRvLKYI0M6wQZ74T _4l_nImwUJnei9zL.ZdGIoxzmg1oO911yupeKD6hz0Y9oEV6DIFU5BJuXQkrPA73jaNV09vD2xrI yAxyLmvpwn3hIAV7.m91aldXwe5hSn0py09acJjixC.U0sQawPwbtKXrSyUNwqvibY3vTMta4pyw UAfW0NLGWlJL0SZCNFwT6QjWUaEuV5QjifXrhlf6TVH1PtGDJ_sMMCr0mTiE9G0JRm9UD4AyKBhI ReiB0WXm.pVmwlPDTd72A4mT6j6vtshETomuIOrLPbTdCe6kOWFgmbbpH4b5Y8OtJaceel5U9dEk zWOqER0062bPpcra9WLAvFDYxoNG2dam73x_ffFK3EJtmchGntx7SFM_5MGFXbZwx1MLUaxsRhT5 Fyr2vpw3BYjT9vvJxOdoENMohVEBKdSrQBESfWFLH4DM6kxt.YqzCwmiGEQc.wuAer1Ak0bSzDHc Ob9HlPCD9YstvnBdpoH1iwWjziKf7mNoXW_hhUbpU54nRJWLc9BsKG40scrjinYzjAHmCqXW324Z 1YMMV3KGVmtJSiugrGlKEoD1j2pxhWOKApoopRnOj45BhuUq5_1gJVjE6SXdj2jIRc9G2Ogh4qob o8cRBhE47hyZBFOXafnGXe87FwEEaP8Hy3XZtJRiCg5vDw737nkeZ4b708eFKgQzmkjqEV10a4So 1AKAqsaLL_bubYbCo42BDtbMW2UN.qqZUwKkSfHM1p15IcCLcySYtExOWh3vIjNudCYpXgvjMWlV 4FJaiWDM.KuQmo0HxmK7236stEI.Di9h7z6fnihQpxTjKamZ_Kwv5FXHtf6SZq_Ma8dHSkzPRgfg OuYaD57OAKtpFR0DCnQnluqI4kEiIJu5Vjzv1hBoo8LK5cZm0dgF_N27WkqkVnRihY_jC6aybyXz PNqY9I0d6E2RBUJK5k22O_JMZiLkwbfgDUGgxxhSqVrQ6yuesWYqNYjibENu.b1Mv7X7wiadKk_Q SrhD7sJk9Ixgkz97UvCa09yBpFzf1bm0Tolld1Ril444ZVIRnrnlkGaeSNhRRUjmeWAeE4XpZrQv seNEAV80vwICOYivamU35G654Uzpuj._ZeOE2DuITcYZZaQvMERzdQpOxVKZfjZftj71S09ae9ky GLR8nbps55ZuubtjiZ9LnRV_XKE7QC7.NvLkoSQFafxz36cbvTZ7JUESX3BFYtBpKr54k2ZwVZiy myog1r0pEQQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Fri, 9 Sep 2022 01:46:54 +0000 Received: by hermes--canary-production-sg3-6bb8946c47-n9zqw (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID e231b3a37c3623fa7c98e5ee6d407780; Fri, 09 Sep 2022 01:46:49 +0000 (UTC) From: Po Lu To: Paul Pogonyshev Subject: Re: bug#57684: locked narrowing breaks existing code without an apparent way to repair References: <2e25ca87e3c6ebb795d7@heytings.org> Date: Fri, 09 Sep 2022 09:46:44 +0800 In-Reply-To: (Paul Pogonyshev's message of "Thu, 8 Sep 2022 22:30:45 +0200") Message-ID: <87o7vp720r.fsf@yahoo.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.20612 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 929 X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57684 Cc: Gregory Heytings , 57684@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Paul Pogonyshev writes: > Good to hear. I think in all cases it should be left to the coder to > temporarily lift restrictions, even if those are "locked", maybe > with strong warnings in documentation. Speed should always > come a second priority to functionality. Besides, Logview (one > example of what would suffer if widening is impossible) is very > fast. > > As an example of why widening might be needed: fontification > may depend on preceding text in the buffer. Maybe standard > Emacs fontification code handles that separately, but e.g. > Logview (almost) completely replaces the standard code here > with a home-grown solution aimed specifically at log files. And > actually this was done exactly for speed. > > Anyway, I hope this is finished soon. For the time being, you can either use an indirect buffer, or run the fontification code in a timer. The former already exists in the wild. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 09 12:17:08 2022 Received: (at 57684) by debbugs.gnu.org; 9 Sep 2022 16:17:08 +0000 Received: from localhost ([127.0.0.1]:35210 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oWggl-0000tX-QT for submit@debbugs.gnu.org; Fri, 09 Sep 2022 12:17:08 -0400 Received: from quimby.gnus.org ([95.216.78.240]:47164) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oWggk-0000sz-Ec for 57684@debbugs.gnu.org; Fri, 09 Sep 2022 12:17:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=MvqP3k7NNWL5ZZB0sE7T/9I5AFzScUOlYH9cRFGbYYg=; b=ixnBrshFN/7iHRe69CRXyN6Exo 25EEz27+ryeFadpqHXPeWckk2k40JLgGRuDhli/BnFWp/WUzVLaQ6NBZFkRRmSzf9LeN/wuyPJM+Y BYPtUsF/V+DnAXPhTVzzu6486VYc/6iOBQ2x29uU79mIIG5+nsv1ifuDsEgNdDBHvLjA=; Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oWggb-0000Tg-7x; Fri, 09 Sep 2022 18:16:59 +0200 From: Lars Ingebrigtsen To: Gregory Heytings Subject: Re: bug#57684: locked narrowing breaks existing code without an apparent way to repair In-Reply-To: <2e25ca87e3c6ebb795d7@heytings.org> (Gregory Heytings's message of "Thu, 08 Sep 2022 19:57:13 +0000") References: <2e25ca87e3c6ebb795d7@heytings.org> X-Now-Playing: Genesis's _And Then There Were Three_: "Many Too Many" Date: Fri, 09 Sep 2022 18:16:55 +0200 Message-ID: <87bkrowmiw.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Gregory Heytings writes: > This issue is being worked on, see the (not yet finished) > feature/improved-locked-narrowing branch. Is there much to be done on that branch before merging? Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57684 Cc: Paul Pogonyshev , 57684@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Gregory Heytings writes: > This issue is being worked on, see the (not yet finished) > feature/improved-locked-narrowing branch. Is there much to be done on that branch before merging? From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 09 12:20:29 2022 Received: (at 57684) by debbugs.gnu.org; 9 Sep 2022 16:20:29 +0000 Received: from localhost ([127.0.0.1]:35226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oWgk0-000109-UT for submit@debbugs.gnu.org; Fri, 09 Sep 2022 12:20:29 -0400 Received: from heytings.org ([95.142.160.155]:33984) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oWgjx-0000zv-H2 for 57684@debbugs.gnu.org; Fri, 09 Sep 2022 12:20:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1662740424; bh=MVylJo8Vxi/p0AZu88vh5WyL4HzK9WjAG4KKjA7q/J0=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=bZoHsQY93kxNJed9batudptxldYHXGJAuRmuhYP0GgxjwAWLcDqqgCu5eEDBzGJkA 6N5lMWBojmT7NzvZchvftM+O6GmclMUFzHHjpgV9RX6FeO/hXWpC2sSFi6AVoNuxZC pEGYff5jBv3ylx3b60FjMFnCopBSRDzYBv5wbTDpCW8M6NJA88h8cMcyts1Hr+9086 xSekG2mmozIqUvIdS1QogaaPNZwcnQncj4K7q2VnQKnfa2zewx0mv3JN/2Ro2OugSO ZX9v5Rq1IgcQtCpytrl3fWg2lJ4jo0FCK2TiUJGaoEoE2jc2SrYq2+dkgm7jROYKur ikUuXv6jiacTg== Date: Fri, 09 Sep 2022 16:20:23 +0000 From: Gregory Heytings To: Lars Ingebrigtsen Subject: Re: bug#57684: locked narrowing breaks existing code without an apparent way to repair In-Reply-To: <87bkrowmiw.fsf@gnus.org> Message-ID: References: <2e25ca87e3c6ebb795d7@heytings.org> <87bkrowmiw.fsf@gnus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57684 Cc: Paul Pogonyshev , 57684@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> This issue is being worked on, see the (not yet finished) >> feature/improved-locked-narrowing branch. > > Is there much to be done on that branch before merging? > I don't know yet. Not "that much" I think, but there are a number of things that need to be fixed/improved. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 13 16:54:28 2022 Received: (at 57684) by debbugs.gnu.org; 13 Sep 2022 20:54:28 +0000 Received: from localhost ([127.0.0.1]:52996 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYCvL-0002OZ-Nj for submit@debbugs.gnu.org; Tue, 13 Sep 2022 16:54:28 -0400 Received: from mail-ej1-f49.google.com ([209.85.218.49]:41523) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYCvJ-0002OJ-Fs for 57684@debbugs.gnu.org; Tue, 13 Sep 2022 16:54:26 -0400 Received: by mail-ej1-f49.google.com with SMTP id gh9so30296480ejc.8 for <57684@debbugs.gnu.org>; Tue, 13 Sep 2022 13:54:25 -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=1mzPbbQMZGQgs7AzoSziuB6jkNV1mLydCFxE3Kr5szg=; b=UZdCWv3JuzmK3+HNIL+CjqdGHI9R70+/xj44JU1MhVq3Lor5B0WoVPYj/ZdOYOP8/H nXohQNEhxiwZLQalp/Vrn557aJ1XPabrXa3rAo3isQNe5OORAm1dLdEWW2/FY9q3yQlY SNnNJ0Fd74VSKYtRTftA3ttU0bz/cJYrDaAjrCykJKIjnz+vCrTEbpDOURmV9RhmCwiS dvA4viGLybPbD0sR/Cy7+599BFgNowD7zQXBccvrOJl/K7PDF9Jm2BQlP6oRhHdtckiX SwVc0muZZK0SjtbtRuA9rvJZKpfmIFkowl0vzN56fIsNvvSHHm4HrIBiODrwoJYvflwT mFtA== 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=1mzPbbQMZGQgs7AzoSziuB6jkNV1mLydCFxE3Kr5szg=; b=X2JAv4yfM+wZ5HIDO80HKYkcIYZdwTXD+212ogzEqcz4SJrU60MJtNcnKLCZz3chgx cvmTf0roVA3MDaEGp1W/SulWp1ZRUUflJAv8wOjBWi/ewUeejFD5bwv337TrbBoiQ7Cq UNGnafRP1KNGR2wrsV8jzoBkH0Caql4tKmw1dzth9+b8CW3bMCjoUJKe0XOjX3IMq8JN OqlaPQVJipRU72cLiAoTBK0ILwhnJQuZHtey60QnQpFyuGdRT5+IQq3retTFFlr07Gln m5jMkr3BQxUhpJhgmaRoxc0vkKWQuqkmniWJlEbjHLurzxuoJojUB0/6T1EWzfz7FFNp u2FQ== X-Gm-Message-State: ACgBeo1gvTDrWtFR8n62VPICJb7UvX0jZhRUzF4ZnhQFFJh18KRITK+r 2Uw0pk9L6MmpZn2nLbPBV8s7Qrn18mJn7cVslg== X-Google-Smtp-Source: AA6agR5zlLbnuCupXatUm8kxUcZFeqe0RdFSqlPOrIQGbxz9IgpcXg/SOqVGpY/Lf1Bz7imSWO+BIQaR3JQF7LKmyU0= X-Received: by 2002:a17:907:75cd:b0:779:5bfe:5d92 with SMTP id jl13-20020a17090775cd00b007795bfe5d92mr18247158ejc.23.1663102459342; Tue, 13 Sep 2022 13:54:19 -0700 (PDT) MIME-Version: 1.0 References: <2e25ca87e3c6ebb795d7@heytings.org> <87bkrowmiw.fsf@gnus.org> In-Reply-To: From: Paul Pogonyshev Date: Tue, 13 Sep 2022 22:54:07 +0200 Message-ID: Subject: Re: bug#57684: locked narrowing breaks existing code without an apparent way to repair To: Gregory Heytings Content-Type: multipart/alternative; boundary="00000000000050753a05e89537cb" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57684 Cc: Lars Ingebrigtsen , 57684@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000050753a05e89537cb Content-Type: text/plain; charset="UTF-8" By the way, today Emacs 29 hung in Magit blaming for me, with C-g doing nothing. Grepping Magit sources suggest it uses the "save-restriction - temporarily widen" more than ten times in various places, 3 of them when blaming. Cannot say for sure that was it, but all the outer symptoms are identical with the hangs in Logview. I really think there must be a way to "widen no matter which locks are installed" - a lot of code seems to depend on that. Paul On Fri, 9 Sept 2022 at 18:20, Gregory Heytings wrote: > > >> This issue is being worked on, see the (not yet finished) > >> feature/improved-locked-narrowing branch. > > > > Is there much to be done on that branch before merging? > > > > I don't know yet. Not "that much" I think, but there are a number of > things that need to be fixed/improved. > --00000000000050753a05e89537cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
By the way, today Emacs 29 hung in Magit blaming for me, w= ith C-g doing nothing. Grepping Magit sources suggest it uses the "sav= e-restriction - temporarily widen" more than ten times in various plac= es, 3 of them when blaming. Cannot say for sure that was it, but all the ou= ter symptoms are identical with the hangs in Logview.

I = really think there must be a way to "widen no matter which locks are i= nstalled" - a lot of code seems to depend on that.

Paul

On Fri, 9 Sept 2022 at 18:20, Gregory Heytings <gregory@heytings.org> wrote:

>> This issue is being worked on, see the (not yet finished)
>> feature/improved-locked-narrowing branch.
>
> Is there much to be done on that branch before merging?
>

I don't know yet.=C2=A0 Not "that much" I think, but there ar= e a number of
things that need to be fixed/improved.
--00000000000050753a05e89537cb-- From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 13 17:06:28 2022 Received: (at 57684) by debbugs.gnu.org; 13 Sep 2022 21:06:28 +0000 Received: from localhost ([127.0.0.1]:53000 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYD6x-0002iM-2D for submit@debbugs.gnu.org; Tue, 13 Sep 2022 17:06:28 -0400 Received: from heytings.org ([95.142.160.155]:39892) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYD6s-0002i9-03 for 57684@debbugs.gnu.org; Tue, 13 Sep 2022 17:06:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1663103180; bh=6vZvrCRnuTRMCpM/BaGPPJHiyImqdAYV5RG4RO0ls+U=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=TYZRb6zqGM87KfEo2/C1eFWArY9mcy+wuwNDzDu0JFCMDZOrVnD7rFPP8Hp5XtP/e UT0EFtdx7WWjoMJjK0RoSTAEIlbpzUpEHTPPYIHia/bmdu+xQoMmkJ7mjtxWFr9nV7 T3h/5WwkqMC+n8eaasXxUFSzAl40wwvY+Wo6EtALrWNAzXeSANgWfxYOiC4y0PU/gn zhO7XYm2s30vfkricc3VeoMQAKKP19KFBm8dBpiQGu56B28xeCeMQL9iOBWqlo4rbZ gxrF/mnixqJioNjfWtHYJoCjviayCwcG6j57L3IAVVjkTb2mMsAjHYYTW8V3g/XxJs l+XZImeBJ/KzA== Date: Tue, 13 Sep 2022 21:06:20 +0000 From: Gregory Heytings To: Paul Pogonyshev Subject: Re: bug#57684: locked narrowing breaks existing code without an apparent way to repair In-Reply-To: Message-ID: References: <2e25ca87e3c6ebb795d7@heytings.org> <87bkrowmiw.fsf@gnus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57684 Cc: Lars Ingebrigtsen , 57684@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > By the way, today Emacs 29 hung in Magit blaming for me, with C-g doing > nothing. Grepping Magit sources suggest it uses the "save-restriction - > temporarily widen" more than ten times in various places, 3 of them when > blaming. Cannot say for sure that was it, but all the outer symptoms are > identical with the hangs in Logview. I really think there must be a way > to "widen no matter which locks are installed" - a lot of code seems to > depend on that. > Yes, we know that, and as I said earlier it will be possible to unlock a locked narrowing. That being said, your description is too vague to draw a conclusion, but given that you tell that Emacs hung in Magit, I'm not quite sure it's locked narrowing that is the culprit. Locked narrowing is currently used only in buffers with very long lines, and only when those buffers are on display. Files with very long lines are typically machine-generated, and not under version control. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 13 17:14:13 2022 Received: (at 57684) by debbugs.gnu.org; 13 Sep 2022 21:14:13 +0000 Received: from localhost ([127.0.0.1]:53020 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYDES-0002uf-QL for submit@debbugs.gnu.org; Tue, 13 Sep 2022 17:14:13 -0400 Received: from mail-ej1-f48.google.com ([209.85.218.48]:41801) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYDEQ-0002uR-GL for 57684@debbugs.gnu.org; Tue, 13 Sep 2022 17:14:10 -0400 Received: by mail-ej1-f48.google.com with SMTP id gh9so30390539ejc.8 for <57684@debbugs.gnu.org>; Tue, 13 Sep 2022 14:14:10 -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=cayuwadojmWvL1lrcYdUb2qJue+OivuAgTGIMs1Z2xg=; b=TxiXHIZN1BiWOL6eSGPc0SDKBkZqG5yV2ZtQnd8kjbC2W3pjtuymDwC0mnyXFCTQhj nbKFOKu694baS2oyP+uH1vDpqEoI/Bqwv9IlbekByDV64QLZarYulsQMjg4C7B5L6mJa HYZ8gSIivdJaPZywEAK5Uxc8zpvnvL5UvyAoGSB+2dwPSIkef29NSvX6PcJLj4nnpFV4 8UCf4m2C0V0/YRux9hdry7V8p+RMGMG7Jo2kz6oMWfUdt11SPsAeD/buW1NMaW5E+W6V c2yVx9zDwbU6EZeGAtXL+K715RBzyyq58ecxHr/f2vNdfyT0Rf/Qzhy3CeAJIIU52Zsx WJ3Q== 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=cayuwadojmWvL1lrcYdUb2qJue+OivuAgTGIMs1Z2xg=; b=EnxHiKPxOHm+eVOblgRzFUeRCjKWu0dtv7LoUnqdhi/3TsvLJu4GIwdajpJqiq/r/1 kP+7ZFRu4je71RacxXUuiEJV6IRNA4nQnIUvEt+IzvgRUbIaL5BW9xPAr+FVnY6K/4VK 1BS5ut8dt46Te7mKykl1CvrYZNOw6mTAdywyQlf5oZW6enDnuQ66YOk1jszuvpSthngu vki4Aos/mbVBuxm/OsMzSi/uYD1ghN+92smZi3zCD5MelAIeG+rnke0rjn9opuNw9N38 WbYSUyAHTVE/Lrw6MwcIpwy0h7OfojDfJXaqq441Qh0EWNcUErgqfLZ8DWF5Al9DanP5 ScAA== X-Gm-Message-State: ACgBeo1rLGyRl/rdNl10q28N+Geksqw4EA4295dQZ9vZMyn6mt02go6w XqH7I/nzFH0BnKxPkGyUVSQdTd+eLOHaHHLAxA== X-Google-Smtp-Source: AA6agR5xdFB0qQP0zQhChL0qLd4RQe7A8ZaXDRlfahBXzIV3+nKQbkNwGp7k/y3CZOMLDMzY92IqpnNXKay2EOSFE90= X-Received: by 2002:a17:907:2c74:b0:77d:5624:6301 with SMTP id ib20-20020a1709072c7400b0077d56246301mr8015523ejc.133.1663103644444; Tue, 13 Sep 2022 14:14:04 -0700 (PDT) MIME-Version: 1.0 References: <2e25ca87e3c6ebb795d7@heytings.org> <87bkrowmiw.fsf@gnus.org> In-Reply-To: From: Paul Pogonyshev Date: Tue, 13 Sep 2022 23:13:52 +0200 Message-ID: Subject: Re: bug#57684: locked narrowing breaks existing code without an apparent way to repair To: Gregory Heytings Content-Type: multipart/alternative; boundary="000000000000f3ade805e8957dec" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57684 Cc: Lars Ingebrigtsen , 57684@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000f3ade805e8957dec Content-Type: text/plain; charset="UTF-8" Well, probably not it then. > Files with very long lines are typically machine-generated Typically, but not always. The Logview hangs for me likely were because the logs I worked with contained long command lines for Java process starting (when you use a huge application with over 100 library JARs, classpath specification can get _really_ long). Actually, in a sense, those are machine-generated too, but the files are meant for human consumption, not e.g. as generated sources that are fed to a compiler. Anyway, I really hope something is done about this soon so that I don't have to switch between Emacs 29 and 28 all the time. Paul On Tue, 13 Sept 2022 at 23:06, Gregory Heytings wrote: > > > > > By the way, today Emacs 29 hung in Magit blaming for me, with C-g doing > > nothing. Grepping Magit sources suggest it uses the "save-restriction - > > temporarily widen" more than ten times in various places, 3 of them when > > blaming. Cannot say for sure that was it, but all the outer symptoms are > > identical with the hangs in Logview. I really think there must be a way > > to "widen no matter which locks are installed" - a lot of code seems to > > depend on that. > > > > Yes, we know that, and as I said earlier it will be possible to unlock a > locked narrowing. That being said, your description is too vague to draw > a conclusion, but given that you tell that Emacs hung in Magit, I'm not > quite sure it's locked narrowing that is the culprit. Locked narrowing is > currently used only in buffers with very long lines, and only when those > buffers are on display. Files with very long lines are typically > machine-generated, and not under version control. > --000000000000f3ade805e8957dec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, probably not it then.

> Files = with very long lines are typically machine-generated

Typically, but not always. The Logview hangs for me likely were because = the=C2=A0logs=C2=A0I worked with contained long command lines for Java proc= ess starting (when you use a huge application with over 100 library JARs, c= lasspath specification can get _really_ long). Actually, in a sense, those = are machine-generated too, but the files are meant for human consumption, n= ot e.g. as generated sources that are fed to a compiler.

Anyway, I really hope something is done about this soon so that I do= n't have to switch between Emacs 29 and 28 all the time.

=
Paul

On Tue, 13 Sept 2022 at 23:06, Gregory Heytings <gregory@heytings.org> wrote:

>
> By the way, today Emacs 29 hung in Magit blaming for me, with C-g doin= g
> nothing. Grepping Magit sources suggest it uses the "save-restric= tion -
> temporarily widen" more than ten times in various places, 3 of th= em when
> blaming. Cannot say for sure that was it, but all the outer symptoms a= re
> identical with the hangs in Logview. I really think there must be a wa= y
> to "widen no matter which locks are installed" - a lot of co= de seems to
> depend on that.
>

Yes, we know that, and as I said earlier it will be possible to unlock a locked narrowing.=C2=A0 That being said, your description is too vague to d= raw
a conclusion, but given that you tell that Emacs hung in Magit, I'm not=
quite sure it's locked narrowing that is the culprit.=C2=A0 Locked narr= owing is
currently used only in buffers with very long lines, and only when those buffers are on display.=C2=A0 Files with very long lines are typically
machine-generated, and not under version control.
--000000000000f3ade805e8957dec-- From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 13 17:36:03 2022 Received: (at 57684) by debbugs.gnu.org; 13 Sep 2022 21:36:03 +0000 Received: from localhost ([127.0.0.1]:53036 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYDZb-0003Sk-L0 for submit@debbugs.gnu.org; Tue, 13 Sep 2022 17:36:03 -0400 Received: from heytings.org ([95.142.160.155]:39926) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYDZY-0003SJ-E6 for 57684@debbugs.gnu.org; Tue, 13 Sep 2022 17:36:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heytings.org; s=20220101; t=1663104959; bh=uSEz1OQ2BDHm5iSpusY9gYzrurl4IV7XIkK87fbqpZQ=; h=Date:From:To:cc:Subject:In-Reply-To:Message-ID:References:From; b=1/AhUPUvdBJTQT2RwzAOU7gi/+SZOw2K2WPxTnVFvjTJZxlRiBXAKbuTW0bURoR0X eHC8NfrmGmJVuttoh0e14iEedBbLpYbMHeASG/6YXB/G/mab74PE5bPPpwmvYhg8ZH 5zikxaFYcmNAOE7dqmzzYEDxCjqytnpZwWgIfWYTGrBZ4Ba+2hLxo6myNWhO4XVn29 YlrX4S2tfGsXkHW9f+jOiBEjU/vPkDBFqL4wCpFIRYgx47+1nyXqNcCgFbEU5VcTSv HuHPLKGH60jVZ3t/8AR3Ier7y7aR1zei9QXTCcUVqHDTEMrJblDEMuQArhCRq551m5 9gmDJqiSBQa9A== Date: Tue, 13 Sep 2022 21:35:58 +0000 From: Gregory Heytings To: Paul Pogonyshev Subject: Re: bug#57684: locked narrowing breaks existing code without an apparent way to repair In-Reply-To: Message-ID: References: <2e25ca87e3c6ebb795d7@heytings.org> <87bkrowmiw.fsf@gnus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57684 Cc: Lars Ingebrigtsen , 57684@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > > Anyway, I really hope something is done about this soon so that I don't > have to switch between Emacs 29 and 28 all the time. > Note that you can safely change long-line-threshold to a somewhat larger value, say 25000, or even 50000. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 13 22:34:23 2022 Received: (at 57684) by debbugs.gnu.org; 14 Sep 2022 02:34:23 +0000 Received: from localhost ([127.0.0.1]:53241 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYIEI-0002kp-MT for submit@debbugs.gnu.org; Tue, 13 Sep 2022 22:34:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33418) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYIEF-0002kY-59 for 57684@debbugs.gnu.org; Tue, 13 Sep 2022 22:34:20 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54570) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYIE9-0005D2-Gj; Tue, 13 Sep 2022 22:34:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=A1XFSyAhzZpXkX4RnSNi2guD2Yw6WRV+imCq8G3CHlo=; b=XorTP8vMtvYq NKtPbidDHGHYzMu1pP3jJ9/+1X8gHZumDHnq3RzxJwMZPHJoklpj7vNYXD1JN1bc4Yyq0fJKasm2D QJ4JAYHAcQq2IoEJqWIBbMbOKDKkREADcoqzEpD9bxjcSxLcQlH8Vi2QEASDw5m5aYZNZvvKNXQsq jsPA7WALhXViXnGyF332EIRZZPiYllKKfx8rZ8d6tstqG+4EuTlYijRkbCz8zWDJDwtqxHtmwtwbh A/dX+angMbPiPn8J8DYTTlAYQohc0Y1pRZnFKXg+vNbgts2W4ZdYErE2DWLFX8Vs0zPXrfQFWoeTE 3gZmzn39XllOsPZ1fzSBLQ==; Received: from [87.69.77.57] (port=1143 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYIE8-0002TO-St; Tue, 13 Sep 2022 22:34:13 -0400 Date: Wed, 14 Sep 2022 05:34:02 +0300 Message-Id: <83y1um3crp.fsf@gnu.org> From: Eli Zaretskii To: Paul Pogonyshev In-Reply-To: (message from Paul Pogonyshev on Tue, 13 Sep 2022 22:54:07 +0200) Subject: Re: bug#57684: locked narrowing breaks existing code without an apparent way to repair References: <2e25ca87e3c6ebb795d7@heytings.org> <87bkrowmiw.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57684 Cc: gregory@heytings.org, larsi@gnus.org, 57684@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: Lars Ingebrigtsen , 57684@debbugs.gnu.org > From: Paul Pogonyshev > Date: Tue, 13 Sep 2022 22:54:07 +0200 > > By the way, today Emacs 29 hung in Magit blaming for me, with C-g doing nothing. Grepping Magit sources > suggest it uses the "save-restriction - temporarily widen" more than ten times in various places, 3 of them > when blaming. Cannot say for sure that was it, but all the outer symptoms are identical with the hangs in > Logview. > > I really think there must be a way to "widen no matter which locks are installed" - a lot of code seems to > depend on that. What does long-line-optimizations-p produce in Magit buffers? If it returns nil, what you see there has nothing to do with locked narrowing, which is only used when buffer text has very long lines. (Magit hides buffer text almost completely, presenting you what is largely overlays and 'display' properties, so you may not be aware of what the actual buffer text looks like.) From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 05:45:22 2022 Received: (at 57684) by debbugs.gnu.org; 14 Sep 2022 09:45:22 +0000 Received: from localhost ([127.0.0.1]:53756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYOxO-0001dy-2K for submit@debbugs.gnu.org; Wed, 14 Sep 2022 05:45:22 -0400 Received: from mail-ej1-f46.google.com ([209.85.218.46]:38773) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYOxL-0001di-Aw for 57684@debbugs.gnu.org; Wed, 14 Sep 2022 05:45:20 -0400 Received: by mail-ej1-f46.google.com with SMTP id u9so33446558ejy.5 for <57684@debbugs.gnu.org>; Wed, 14 Sep 2022 02:45:19 -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=G28U4RpC2/NLEbifW0zYiyYlJZFrijOMveSTqBovMFQ=; b=dcc78bHo+7uhfQDm8y+LT+gB1UOfwrsxIf+okqHHdnVreS0ivLR0SKwp5L5cGIEwsq hgnAi1qxnpmyEDiZr/r7/1Ker7Q/P+yI3Y69/pmgUw/FGUjsuXWPMQqEnwBZAuCn2gMf Ed3kt0cvOD3C09HG+OoB7xdwTwkHkWiMLDRbY0zp1l2qD6UbSfyUaJbcUxujHISvGpb0 XgOQeHgPUbztMbgGsuO4isGOwKa1HrSENC5ljDv6yR2wH8AiTMbqW8zbQRK/5pxinUSy 8Z0q/hE25cRZrquGBwFWsVnSRZROJp5XuICmEOCmpvjqUwfIv6Z12eLgjLI6iuqkN+3C XMpg== 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=G28U4RpC2/NLEbifW0zYiyYlJZFrijOMveSTqBovMFQ=; b=5gXSY6qHA72nIdaK1rU5HjMmde87Tls5YgFK0UzlC4HyU9i2SJMxjZja8DnfdxI0ph KOrQMbI3NwKlva6Ok5is/HxFagQBQUXODci3Ra3UiMdn5jgAD3EWy0iawihLHDqDh5U4 T86xkkK63driYShPw2YGKPNlHUOPM3a2doIYzNE9IBI8d6/8c7PvhML+av74zNJ84JDi 1BYgNOMa2I3Tind/fvr7LSX+cWhrHM9A/sUxzPgd/wSI3pvvLb7iXK1NQxlJLmge38Ic qY/NnWI4AGGBLAJEfFpmKSgq0Uk4DhpgJgc0zdrl5QteZEX+8RHe81wjAoD+IdMpZngX XCoQ== X-Gm-Message-State: ACgBeo3/nM0/Ip+QGFzqtzyfCb1L1EVO0Ws7Lt5QfTl4n6mfUaohQnfc BQREDTlJUJ05v2yb7AvR/3+9omS90F4o7g/zuA== X-Google-Smtp-Source: AA6agR5ihcf4YqHD6qnEUK55PSG8U9/cZk7x/3vE8zA7qu9OamEn4QmnfoFx4DNMBAGDQNQbbo78+ohbFLtMjGI6S5A= X-Received: by 2002:a17:907:2c74:b0:77d:5624:6301 with SMTP id ib20-20020a1709072c7400b0077d56246301mr9535252ejc.133.1663148713348; Wed, 14 Sep 2022 02:45:13 -0700 (PDT) MIME-Version: 1.0 References: <2e25ca87e3c6ebb795d7@heytings.org> <87bkrowmiw.fsf@gnus.org> <83y1um3crp.fsf@gnu.org> In-Reply-To: <83y1um3crp.fsf@gnu.org> From: Paul Pogonyshev Date: Wed, 14 Sep 2022 11:45:01 +0200 Message-ID: Subject: Re: bug#57684: locked narrowing breaks existing code without an apparent way to repair To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000004494bf05e89ffcea" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 57684 Cc: Gregory Heytings , Lars Ingebrigtsen , 57684@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000004494bf05e89ffcea Content-Type: text/plain; charset="UTF-8" No, that's not it, I have checked now. Also, blaming is done in normal file buffers, not in the status buffer. By the way, it would really be nice if Emacs could do something about hangs irrespective of what causes that. Even if Elisp code is buggy, Emacs itself should never allow it to fall into an infinite loop and stop responding to C-g, leaving full restart as the only way out. Paul On Wed, 14 Sept 2022 at 04:34, Eli Zaretskii wrote: > > Cc: Lars Ingebrigtsen , 57684@debbugs.gnu.org > > From: Paul Pogonyshev > > Date: Tue, 13 Sep 2022 22:54:07 +0200 > > > > By the way, today Emacs 29 hung in Magit blaming for me, with C-g doing > nothing. Grepping Magit sources > > suggest it uses the "save-restriction - temporarily widen" more than ten > times in various places, 3 of them > > when blaming. Cannot say for sure that was it, but all the outer > symptoms are identical with the hangs in > > Logview. > > > > I really think there must be a way to "widen no matter which locks are > installed" - a lot of code seems to > > depend on that. > > What does long-line-optimizations-p produce in Magit buffers? If it > returns nil, what you see there has nothing to do with locked > narrowing, which is only used when buffer text has very long lines. > > (Magit hides buffer text almost completely, presenting you what is > largely overlays and 'display' properties, so you may not be aware of > what the actual buffer text looks like.) > --0000000000004494bf05e89ffcea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No, that's not it, I have checked now. Also, blaming i= s done in normal file buffers, not in the status buffer.

By the way, it would really be nice if Emacs could do something about hang= s irrespective of what causes that. Even if Elisp code is buggy, Emacs itse= lf should never allow it to fall into an infinite loop and stop responding = to C-g, leaving full restart as the only way out.

= Paul

On Wed, 14 Sept 2022 at 04:34, Eli Zaretskii <eliz@gnu.org> wrote:
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 57684@debbugs.gnu.org
> From: Paul Pogonyshev <pogonyshev@gmail.com>
> Date: Tue, 13 Sep 2022 22:54:07 +0200
>
> By the way, today Emacs 29 hung in Magit blaming for me, with C-g doin= g nothing. Grepping Magit sources
> suggest it uses the "save-restriction - temporarily widen" m= ore than ten times in various places, 3 of them
> when blaming. Cannot say for sure that was it, but all the outer sympt= oms are identical with the hangs in
> Logview.
>
> I really think there must be a way to "widen no matter which lock= s are installed" - a lot of code seems to
> depend on that.

What does long-line-optimizations-p produce in Magit buffers?=C2=A0 If it returns nil, what you see there has nothing to do with locked
narrowing, which is only used when buffer text has very long lines.

(Magit hides buffer text almost completely, presenting you what is
largely overlays and 'display' properties, so you may not be aware = of
what the actual buffer text looks like.)
--0000000000004494bf05e89ffcea-- From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 14 07:57:34 2022 Received: (at 57684) by debbugs.gnu.org; 14 Sep 2022 11:57:34 +0000 Received: from localhost ([127.0.0.1]:53997 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYR1K-0007WJ-4s for submit@debbugs.gnu.org; Wed, 14 Sep 2022 07:57:34 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46326) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oYR1I-0007W5-87 for 57684@debbugs.gnu.org; Wed, 14 Sep 2022 07:57:33 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36870) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYR19-00015U-OS; Wed, 14 Sep 2022 07:57:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Ktk0119RAYFmmtl08RwYA0xevSfanOId9K0GEY7i56g=; b=phZwWFNNHbiE Y2A7626WRHnz6nTtpnbmSFLCndHkq7Vv9pMx4X/sQzkq+S+kSMthIfpH/WsNNHlZnaehp6WWGjEGw 1PAnVsecPIX60BAWET8T3862a1xMmOLUlmXwVQKueA6CowKwrkCMMP0kuBU2jdskxP/YNlVYVG7K8 AUW3iyuKETxpidinOT8Q/oPOvTEvcavdl8sio6zve0AztMHJU/fF03rDz3k54/83OP8rv/g4Rg6wn 8JPkbbY3+H3H3+nDMHkwlpOCl/AEoYXIu1JZQFLGOW/oeioUac56FdSpJGVUvAsMUCnI/Lb5aphoM QWS0US4SRTbWEvtGXdYQRA==; Received: from [87.69.77.57] (port=3581 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYR17-0005pK-8c; Wed, 14 Sep 2022 07:57:22 -0400 Date: Wed, 14 Sep 2022 14:57:11 +0300 Message-Id: <83illq2mp4.fsf@gnu.org> From: Eli Zaretskii To: Paul Pogonyshev In-Reply-To: (message from Paul Pogonyshev on Wed, 14 Sep 2022 11:45:01 +0200) Subject: Re: bug#57684: locked narrowing breaks existing code without an apparent way to repair References: <2e25ca87e3c6ebb795d7@heytings.org> <87bkrowmiw.fsf@gnus.org> <83y1um3crp.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57684 Cc: gregory@heytings.org, larsi@gnus.org, 57684@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Paul Pogonyshev > Date: Wed, 14 Sep 2022 11:45:01 +0200 > Cc: Gregory Heytings , Lars Ingebrigtsen , 57684@debbugs.gnu.org > > By the way, it would really be nice if Emacs could do something about hangs irrespective of what causes > that. Even if Elisp code is buggy, Emacs itself should never allow it to fall into an infinite loop and stop > responding to C-g, leaving full restart as the only way out. I think that's impossible in general, unless we restrict what Lisp programs can do. Every programming language can be used to write a buggy program. However, it should be possible to prevent some cases of such problematic behavior, certainly so when the infloop is caused by our bug. But for that we need to know the details of the specific case in order to investigate. From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 15 23:38:26 2022 Received: (at 57684) by debbugs.gnu.org; 16 Sep 2022 03:38:26 +0000 Received: from localhost ([127.0.0.1]:41085 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ2BN-0003So-PR for submit@debbugs.gnu.org; Thu, 15 Sep 2022 23:38:26 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55982) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ2BJ-0003SY-K5 for 57684@debbugs.gnu.org; Thu, 15 Sep 2022 23:38:24 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60020) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZ2BE-0001Rd-DL for 57684@debbugs.gnu.org; Thu, 15 Sep 2022 23:38:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=LFcm8VpVGzNjFMg+49N0Z3908JmN4BW5GIcOh+ig2OI=; b=dYMRIJX4AIwq hLykw/hl21D7Kaw6emW5v05zz7LTDJpwoWNX8EHEIXJz/tMzD+zie4kNiSaCq7Q6u6GJAH0ioLn4N Hd+OM7yos4rFcX2Wc4E3CogoTZnuIAX9rVNUBEv+lG7FPihIaqH2ep6pqrV44hr3OvL8xC6Oh+Ozg oEPdw5nOUeohr4YApbAFpc4/BbkAHcKIDPn3Kh3StFR2EDUdk0yGCTuzXL2cG30iJc1SW0pvzQg80 nn1+zUjQtZedtV/xMsppjWMNsYvJCzLiQH623+tENmz2UNy7BTE2tV1YwV2GwcOfvB1c+Qq/ta5BH S5dGhyMzn2zHkUMBsgmT3Q==; Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1oZ2BD-0003e5-LZ; Thu, 15 Sep 2022 23:38:15 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: Eli Zaretskii In-Reply-To: <83illq2mp4.fsf@gnu.org> (message from Eli Zaretskii on Wed, 14 Sep 2022 14:57:11 +0300) Subject: Re: bug#57684: locked narrowing breaks existing code without an apparent way to repair References: <2e25ca87e3c6ebb795d7@heytings.org> <87bkrowmiw.fsf@gnus.org> <83y1um3crp.fsf@gnu.org> <83illq2mp4.fsf@gnu.org> Message-Id: Date: Thu, 15 Sep 2022 23:38:15 -0400 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57684 Cc: 57684@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Even if Elisp code is buggy, Emacs itself should never allow it to fall into an infinite loop and stop > > responding to C-g, leaving full restart as the only way out. It used to be impossible to have an infinite loop in Emacs Lisp that you could not quit out of. The Lisp interpreter and tye bytecode interpreter both had calls to QUIT in all the loops of Lisp execution. Likewise, all the loops in C code that corresponded to Lisp loops, and might fail to terminate if given circular lists, such as Fmemq, had calls to QUIT. If that is now no longertrue, what made it cease to be true? -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 16 02:04:45 2022 Received: (at 57684) by debbugs.gnu.org; 16 Sep 2022 06:04:45 +0000 Received: from localhost ([127.0.0.1]:41275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ4Sy-0001BZ-Ts for submit@debbugs.gnu.org; Fri, 16 Sep 2022 02:04:45 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38818) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZ4Sw-0001BM-MK for 57684@debbugs.gnu.org; Fri, 16 Sep 2022 02:04:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50522) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZ4Sr-0005Jh-HV for 57684@debbugs.gnu.org; Fri, 16 Sep 2022 02:04:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Z2iWIMShR68krk9g6uuXV+UDGobuQNDlaYkvLQXj+jg=; b=PkjOIzFU7sE+ wYLHEASZMS4G1/G8IQoGDkbjGuTFqHBVkogjVwPcPGEqg6TIKDiqPL7Q3QoPH+H8+VdM6ne3LfqL2 TrgRZWL0GA4nXecFxK9kyIsX42fYKcABZz0ltB4QkZK/evQBhzyQi+/6f52ousV8oIBkNvIVu4tvK 5y+vOs60poGAIL6hRTV7iwbI5bKV6A7e07X0NmKjAFKTIrEkB/P35HXdDMZRGr29ur5ueBxTyhWhx ciMue93zQeo3Hzb3jQwblNU/CpXA2Bd65VGd60QTSz9NcFn1nVyKmGDbZA/B6EKkBdGhzRLyWDjbg /exYDVAOZotG4qq9ENSAug==; Received: from [87.69.77.57] (port=2892 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZ4So-0006PZ-9X; Fri, 16 Sep 2022 02:04:34 -0400 Date: Fri, 16 Sep 2022 09:04:28 +0300 Message-Id: <83sfkr4zyr.fsf@gnu.org> From: Eli Zaretskii To: rms@gnu.org In-Reply-To: (message from Richard Stallman on Thu, 15 Sep 2022 23:38:15 -0400) Subject: Re: bug#57684: locked narrowing breaks existing code without an apparent way to repair References: <2e25ca87e3c6ebb795d7@heytings.org> <87bkrowmiw.fsf@gnus.org> <83y1um3crp.fsf@gnu.org> <83illq2mp4.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57684 Cc: 57684@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Richard Stallman > Cc: 57684@debbugs.gnu.org > Date: Thu, 15 Sep 2022 23:38:15 -0400 > > > Even if Elisp code is buggy, Emacs itself should never allow it to fall into an infinite loop and stop > > > responding to C-g, leaving full restart as the only way out. > > It used to be impossible to have an infinite loop in Emacs Lisp that > you could not quit out of. The Lisp interpreter and tye bytecode > interpreter both had calls to QUIT in all the loops of Lisp execution. > Likewise, all the loops in C code that corresponded to Lisp loops, and > might fail to terminate if given circular lists, such as Fmemq, > had calls to QUIT. > > If that is now no longertrue, what made it cease to be true? It is still true. The problem exists only with Lisp code that is run when QUITs are either intentionally disabled, or when Lisp is run from the display engine, where QUIT is caught and basically ignored. The particular case which started this thread is of the latter variety. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 16 23:40:31 2022 Received: (at 57684) by debbugs.gnu.org; 17 Sep 2022 03:40:31 +0000 Received: from localhost ([127.0.0.1]:44769 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZOgw-00020p-P5 for submit@debbugs.gnu.org; Fri, 16 Sep 2022 23:40:31 -0400 Received: from eggs.gnu.org ([209.51.188.92]:52532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZOgr-00020K-4q for 57684@debbugs.gnu.org; Fri, 16 Sep 2022 23:40:29 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45734) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZOgl-0003on-VU for 57684@debbugs.gnu.org; Fri, 16 Sep 2022 23:40:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=o/M4ugtW+Bxy2mBHdFAN0SL/45FFTbXfBVbEYRZ/S7w=; b=DlNzaJLxz6Xa rfD+g1mSBvIdDhP+loUOWPeuxYaI4OIGhEDzN2YTNF3+DnTi6Q6fTpxBHLgqnGMun/i5G3rr3HKb4 jYYkybmEBYZbymmLPHLc6HYfzBX67X2GitA4zK4PTTGBNiw/6fJi/0UT6F1Q8U6Ab0IliqKScPuPQ Qby+gEyE1WRVmRx1oPE/BadJaX7pVRRaOut6qhmC+SgLuDOO1RBI4cm5i4Fh5Xf9gqQ6j/SUaSOSL NOwO0gAqMFruf2v1vou2lZYu8Un5qT4NVCj6dUi/aeSYyJa7z7KEZHFs9S54N5Gna4EQv3GstZPer VTvPzta721Ci2oAAD1dT4w==; Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1oZOgl-00080D-M6; Fri, 16 Sep 2022 23:40:19 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: Eli Zaretskii In-Reply-To: <83sfkr4zyr.fsf@gnu.org> (message from Eli Zaretskii on Fri, 16 Sep 2022 09:04:28 +0300) Subject: Re: bug#57684: locked narrowing breaks existing code without an apparent way to repair References: <2e25ca87e3c6ebb795d7@heytings.org> <87bkrowmiw.fsf@gnus.org> <83y1um3crp.fsf@gnu.org> <83illq2mp4.fsf@gnu.org> <83sfkr4zyr.fsf@gnu.org> Message-Id: Date: Fri, 16 Sep 2022 23:40:19 -0400 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57684 Cc: 57684@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > It is still true. The problem exists only with Lisp code that is run > when QUITs are either intentionally disabled, or when Lisp is run from > the display engine, where QUIT is caught and basically ignored. The > particular case which started this thread is of the latter variety. I never allowed redisplay to run Lisp code -- it seemed very dangerous. An error there could leave redisplay data structures inconsistent. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 17 02:33:23 2022 Received: (at 57684) by debbugs.gnu.org; 17 Sep 2022 06:33:23 +0000 Received: from localhost ([127.0.0.1]:45000 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZROF-0006cz-FT for submit@debbugs.gnu.org; Sat, 17 Sep 2022 02:33:23 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZROA-0006cj-AH for 57684@debbugs.gnu.org; Sat, 17 Sep 2022 02:33:21 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:50022) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZRO5-00023Z-4O for 57684@debbugs.gnu.org; Sat, 17 Sep 2022 02:33:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=KiSSamQRa0sSlCeuI8L+MZR2mU07PqmR8Bk3tmlHgDc=; b=HzQ0WiH0y3zR h7atbiBCOYnL0kRUs52aog/+7QwZFITyZXN2sOefMJp79vI5R7sWtrthKuO0q1dNR2mu6FjkE5axm 3XBACkYIp6jj6VyBHES3oZoaTfy5bzhg0RMi2XFBFWuTcaQt6UPV92Nk4bkfttc7nPpj9IxKt4QiT HeQ51tiKv8/B4EsweVb1OV1NAe0NjP9UuLikBao8jVYkR5T556AvXlWNGuI7Caoxr24rl4WXdHAky KPjuiz1n3skB+X1o5Lb3zaK8RMidoXWRwNUrhMG1gwq9xhrd9dy7vHJhfDNdkr4aTEYAx8dABXeTb eV3JSMQWasJKFytq6ha7EA==; Received: from [87.69.77.57] (port=1410 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZRO0-0006eN-Md; Sat, 17 Sep 2022 02:33:09 -0400 Date: Sat, 17 Sep 2022 09:33:06 +0300 Message-Id: <83czbu33z1.fsf@gnu.org> From: Eli Zaretskii To: rms@gnu.org In-Reply-To: (message from Richard Stallman on Fri, 16 Sep 2022 23:40:19 -0400) Subject: Re: bug#57684: locked narrowing breaks existing code without an apparent way to repair References: <2e25ca87e3c6ebb795d7@heytings.org> <87bkrowmiw.fsf@gnus.org> <83y1um3crp.fsf@gnu.org> <83illq2mp4.fsf@gnu.org> <83sfkr4zyr.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 57684 Cc: 57684@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Richard Stallman > Cc: 57684@debbugs.gnu.org > Date: Fri, 16 Sep 2022 23:40:19 -0400 > > > It is still true. The problem exists only with Lisp code that is run > > when QUITs are either intentionally disabled, or when Lisp is run from > > the display engine, where QUIT is caught and basically ignored. The > > particular case which started this thread is of the latter variety. > > I never allowed redisplay to run Lisp code -- it seemed very dangerous. > An error there could leave redisplay data structures inconsistent. That ship sailed a long time ago: Emacs 21 introduced jit-lock.el, which is a way of running font-lock as part of redisplay, on the portion of the buffer which is about to be displayed. This is on by default since Emacs 21. In addition, we have several hooks, notably window-scroll-functions, which redisplay runs when appropriate. Search xdisp.c for "safe_call" to see where and why we call Lisp from redisplay. Yes, it's somewhat dangerous, and caused us nontrivial issues over the years, but I don't think it's possible to go back to not calling Lisp from the display code.