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#57684: locked narrowing breaks existing code without an apparent way to repair Date: Wed, 14 Sep 2022 11:45:01 +0200 Message-ID: References: <2e25ca87e3c6ebb795d7@heytings.org> <87bkrowmiw.fsf@gnus.org> <83y1um3crp.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000004494bf05e89ffcea" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25215"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Gregory Heytings , Lars Ingebrigtsen , 57684@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 14 11:46:16 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 1oYOyF-0006Mv-MF for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 14 Sep 2022 11:46:15 +0200 Original-Received: from localhost ([::1]:48496 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oYOyD-0003nc-W8 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 14 Sep 2022 05:46:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35010) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oYOy3-0003ms-32 for bug-gnu-emacs@gnu.org; Wed, 14 Sep 2022 05:46:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36824) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oYOy2-00019Z-Od for bug-gnu-emacs@gnu.org; Wed, 14 Sep 2022 05:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oYOy2-0001ev-A5 for bug-gnu-emacs@gnu.org; Wed, 14 Sep 2022 05:46: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: Wed, 14 Sep 2022 09:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57684 X-GNU-PR-Package: emacs Original-Received: via spool by 57684-submit@debbugs.gnu.org id=B57684.16631487226327 (code B ref 57684); Wed, 14 Sep 2022 09:46:02 +0000 Original-Received: (at 57684) by debbugs.gnu.org; 14 Sep 2022 09:45:22 +0000 Original-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 Original-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 Original-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) In-Reply-To: <83y1um3crp.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:242441 Archived-At: --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--