bug#56393: Actually fix the long lines display bug

[Eli Zaretskii]

> Date: Wed, 06 Jul 2022 13:56:06 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, 56393@debbugs.gnu.org
> 
> > 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?
> 
> I don't know.  I only observe that it's often unable to cope with such 
> cases.  And this is outside of the scope of the long line display bug, 
> it's (possibly) a font-lock bug (or an inherent limitation of font-lock). 
> I can try to tackle that bug next, if you want.

I think we must, because font-lock is run by the display engine, and
if font-lock makes redisplay significantly slower, it's part of the
same problem.

> >> 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.
> >
> 
> Okay.  My opinion is that being able to edit a file normally without nice 
> colors on its characters is way better than being unable to edit a file. 

Oh, we agree here: it's definitely way better.  I'm just saying that a
complete solution cannot force users to make such sacrifices.

> >>> 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.
> 
> It's never a no-op when it is used as a command.  It can become a no-op 
> when it is used internally by a command.

I understand.  And that means some of those callers will work
differently under auto-narrow-mode than they do without.  Which is not
a good thing to have.

Why is 'recenter' at all relevant, btw?  It isn't called by the
display code, AFAIR, so why do we have to disable it?

> >>> 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.
> 
> Narrowing has been in Emacs since about forever, so as far as I can tell 
> functions that were written without taking the possibility that the buffer 
> on display is narrowed into account, and that do not work anymore when the 
> buffer is narrowed, have a bug.

I think there's a misunderstanding here: what these Lisp programs
don't expect is to find narrowing that is different from what the user
sees or expects top have.  Narrowing is largely a user-level feature,
so using it for internal purposes is problematic at best.