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

[Paul Pogonyshev <pogonyshev@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1711 bytes --]

Well, probably not it then.

> Files with very long lines are typically machine-generated

Typically, but not always. The Logview hangs for me likely were because
the logs I worked with contained long command lines for Java process
starting (when you use a huge application with over 100 library JARs,
classpath specification can get _really_ long). Actually, in a sense, those
are machine-generated too, but the files are meant for human consumption,
not e.g. as generated sources that are fed to a compiler.

Anyway, I really hope something is done about this soon so that I don't
have to switch between Emacs 29 and 28 all the time.

Paul

On Tue, 13 Sept 2022 at 23:06, Gregory Heytings <gregory@heytings.org>
wrote:

>
> >
> > 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.
> >
>
> Yes, we know that, and as I said earlier it will be possible to unlock a
> locked narrowing.  That being said, your description is too vague to draw
> a conclusion, but given that you tell that Emacs hung in Magit, I'm not
> quite sure it's locked narrowing that is the culprit.  Locked narrowing is
> currently used only in buffers with very long lines, and only when those
> buffers are on display.  Files with very long lines are typically
> machine-generated, and not under version control.
>

[-- Attachment #2: Type: text/html, Size: 2220 bytes --]