bug#57684: locked narrowing breaks existing code without an apparent way to repair

[Paul Pogonyshev]

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 <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 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.)