GNU bug report logs - #57684
locked narrowing breaks existing code without an apparent way to repair

Previous Next

Full log

Message #35 received at 57684 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Pogonyshev <pogonyshev <at> gmail.com>
Cc: gregory <at> heytings.org, larsi <at> gnus.org, 57684 <at> debbugs.gnu.org
Subject: Re: bug#57684: locked narrowing breaks existing code without an
 apparent way to repair
Date: Wed, 14 Sep 2022 05:34:02 +0300

> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 57684 <at> debbugs.gnu.org
> From: Paul Pogonyshev <pogonyshev <at> 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 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.)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.