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