GNU bug report logs -
#57684
locked narrowing breaks existing code without an apparent way to repair
Previous Next
Full log
Message #38 received at 57684 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> gnu.org> wrote:
> > 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.)
>
[Message part 2 (text/html, inline)]
This bug report was last modified 2 years and 274 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.