bug#56393: Actually fix the long lines display bug

[Gregory Heytings]

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

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

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

> 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?  Or IOW, Lisp 
code that expects to have access to the entire buffer without being 
embedded is such a form has a bug, isn't it?