bug#56393: Actually fix the long lines display bug

[Eli Zaretskii]

> Date: Tue, 05 Jul 2022 13:53:36 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: 56393@debbugs.gnu.org
> 
> >> -** 'longlines-mode' is no longer obsolete.
> >
> > Likewise here.
> >
> 
> This mode was unobsoleted a few days ago, because the conclusion was that 
> there was no better mechanism available to cope with large files.  Now 
> there is.

Well, the cursor motion problems I mentioned? longlines doesn't have
them.

> > This will invoke auto-narrow-mode for any file that is for some reason 
> > inserted by Emacs into some buffer.  Many Emacs commands insert files 
> > into temporary buffers or buffers that are never meant for display, and 
> > AFAIU the above will narrow such a buffer if a file inserted happens to 
> > have long lines, is that correct?
> 
> It might, everything is possible with software.  Let's see if it happens 
> in practice and take the appropriate measure if it happens.

I did try this, and it does happen.  Here:

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

> And the cure for these potential cases is easy: (let
> ((auto-narrow-long-line-threshold nil)) ...)

Where do you suggest doing this?

> > I don't quite see clearly what these general issues could mean, but they 
> > are at least worrisome, I think, because they could potentially mean 
> > significant breakage in many places.
> >
> 
> Again, let's see if it happens in practice and take the appropriate 
> measure if it actually happens.

See above.  I think it will happen quite a lot in the wild.

> > Also for commands written by users: for example, if someone writes a 
> > command that is a trivial wrapper around goto-line, that command will no 
> > longer automatically widen as goto-line does, right?
> 
> Indeed, that's the purpose of the auto-narrow-widen-automatically 
> defcustom: users can easily add their own commands to that list.

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.

> > Alternatively, maybe you will explain that I'm bothered by a 
> > non-existent problem?
> 
> What I think is that you are bothered with a potential problem which is 
> far less important than seeing Emacs becoming unresponsive.

I'm not sure.  A broken command might be important, especially if this
feature is going to be on by default.

> > Since the narrowing is basically in effect only during redisplay, it 
> > doesn't help with commands that use display code outside of redisplay 
> > proper.  For example, C-n, C-v, C-l, and other commands are still 
> > extremely sluggish in files with long lines.  E.g., try the file 
> > long-line.xml mentioned here:
> >
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45898#80
> 
> Did you actually try the patch?

Yes.

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