bug#56393: Actually fix the long lines display bug

[Eli Zaretskii]

> Date: Tue, 05 Jul 2022 14:30:08 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 56393@debbugs.gnu.org
> 
> 
> >  (with-temp-buffer
> >    (insert-file-contents "long-line.xml")
> >    (point-max))
> >
> > (where long-line.xml is the file whose URL I've shown in my message). 
> > This gives me 30001, whereas the correct value is 306666.
> >
> 
> That's of course not what I meant with "in practice".  What I meant is: 
> are there actual uses of "(with-temp-buffer (insert-file-contents ..." 
> which insert actual files with sufficiently long lines?  Such files are 
> not so common.

JSON files are quite frequently like that, for example.  (One of the
files mentioned in bug#45898 is such a file.)

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

> > That means the list will be very long and users will have to constantly 
> > update it.  E.g., whenever they install a new package or even a new 
> > version of a package.
> 
> Packages can take care of this by themselves, can't they?  When the 
> package is loaded, (add-to-list auto-narrow-widen-automatically 
> the-package-command).

I don't like this.  And neither will package maintainers, I think.

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.

> >>> Also, the automatic restriction is very visible and causes surprising 
> >>> effects: (point-min) and (point-max) evaluate to the narrowed region 
> >>> (so it's basically very hard to know the real size of the buffer), and 
> >>> scrolling through the buffer causes the scroll-bar thumb move in a 
> >>> non-monotonic manner: I scroll towards the end of the buffer, but the 
> >>> thumb sometimes jumps back up, as if I moved towards the beginning.
> >>
> >> Indeed.  Users will see the "Auto-Narrow" indication in the modeline 
> >> with which they can easily find an explanation for that behavior.  If 
> >> this behavior is problematic, it could be fixed by using the dimensions 
> >> of the whole buffer when updating the scroll bar (and perhaps also the 
> >> modeline), when auto-narrow-mode is active.
> >
> > I think it should be fixed, yes.
> >
> 
> Okay, I'll see what I can do.

Thanks.