bug#56393: Actually fix the long lines display bug

[Gregory Heytings]

> > As I said, if that's the case, it's easy to add a "(let 
> > ((auto-narrow-long-line-threshold nil))" around the code, in this case 
> > either in the with-temp-buffer macro or in the code above.
>
> These macros are called a lot, and I don't think it's a good idea to 
> tell all their callers to make such changes.

As I said, this can also be done inside the with-temp-buffer macro.  A 
(very quick) review of calls to insert-file-contents in Emacs core and 
ELPA tells me that that the majority of these calls are inside a 
with-temp-buffer or with-current-buffer (with a temporary buffer).

> I think we should try to work out a solution that only affects the C 
> code in the display engine, such that any Lisp called from the various 
> hooks and places in display code is not affected, and neither are 
> pre-command-hook and post-command-hook.  That should have almost the 
> same effect, performance-wise, but be much safer than the automatic 
> narrowing that affects everything in Emacs as long as the narrowing is 
> in effect.
>
> IOW, replace all BEGV and ZV in display code with a couple of new 
> macros, which effectively "narrow" the buffer, as far as the display 
> engine is concerned.  Then set the limits of this restriction in 
> redisplay_window, and remove it when the window's redisplay is done. Or 
> something along these lines.

I guess this means, in essence, to throw away the patch?  Or do I 
interpret what you wrote too negatively?