bug#56393: Actually fix the long lines display bug

[Eli Zaretskii]

> Date: Wed, 06 Jul 2022 13:01:39 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, 56393@debbugs.gnu.org
> 
> > I think we should decide what kind of feature this one is supposed to 
> > be.  Is this really the full and complete solution of the long-line 
> > display problems, or is this just a way to prevent Emacs from being 
> > sluggish/not responsive by any means deemed necessary?
> 
> As far as I can tell, it's a full and complete solution, which makes a few 
> compromises (as few as possible).

Depending on the compromise, that might or might not qualify as a full
and complete solution.  Font-lock is a very important feature, so
disabling it sounds like a heavy price to pay.  Especially since I
don't understand why: if the buffer is narrowed to 30K characters, why
should font-lock be unable to cope?

> > If this is supposed to be the complete solution, such that we don't need 
> > any others, then it shouldn't interfere with editing and shouldn't 
> > disable useful features such as font-lock,
> 
> Font locking is as far as I can see the main reason why Emacs is still a 
> bit sluggish in such cases.  Font locking is surely a useful feature, but 
> it's not essential to edit a file.

Well, I disagree it's non-essential.

> And users who for some reason prefer not to disable font locking can
> do so by removing turn-off-font-lock-mode from the auto-narrow-mode
> hook.

I'm talking about the defaults here.  The defaults should allow
editing without sacrificing important features (and ideally without
sacrificing anything).  Otherwise, this isn't a solution, it's a
workaround.  Which is also fine, but we should recognize it as such.

> > shouldn't make commands a no-op (as it does now with 'recenter'),
> 
> It's not no-op, it's no-op when if and only if it is called on a 
> temporarily widened buffer when auto-narrow-mode is on.  So you can still 
> use C-l as usual everywhere.

It shouldn't be a no-op under any circumstances.  It's an important
command.

> > and shouldn't get in the way of Lisp code that expects to have access to 
> > the entire buffer when it has no reason to expect narrowing.
> >
> 
> Lisp code that expects to have access to the entire buffer is typically 
> embedded in a (save-restriction (widen) ...) form, isn't it?

No, not necessarily.  Lisp code that doesn't expect to find narrowing
simply does nothing about narrowing.