bug#56393: Actually fix the long lines display bug

[Eli Zaretskii]

> Cc: 56393@debbugs.gnu.org
> Date: Tue, 05 Jul 2022 23:12:45 +0000
> From: Gregory Heytings <gregory@heytings.org>
> 
> 
> >
> > Would it be feasible to combine Gregory's work here with the new ticks 
> > code?
> >
> > That is, not enabling the new mode by default in all buffers, but if 
> > we've registered that a particular window has generated a lot of ticks, 
> > then we check the buffer for long lines and then enable the mode in that 
> > buffer.
> >
> > I.e., postpone enabling the mode until we see that we need it.  That 
> > should make most programmatic usages not trigger the mode.
> >
> 
> Our mails crossed each other: the problem of programmatic usages is now 
> solved AFAICS.

Thanks, it's definitely better now.  However, not all the issues with
Lisp programs are gone, AFAICT.  At least the hooks called from
redisplay, like window-scroll-functions, still see a narrowed buffer.

Functions that are run by timers will also see a narrowed buffer.

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?

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, shouldn't make
commands a no-op (as it does now with 'recenter'), 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.  IOW, it should
affect only the display code and nothing else.

It is also possible and useful to have a partial solution, which makes
redisplay perform reasonably well at a price of disabling some
features and commands, and perhaps breaking some code out there.  But
then IMO it can no longer be the only such feature; instead, it is one
of several alternatives that attempt to unwedge redisplay by taking
different kinds of measures, each one with its advantages and
disadvantages.  As a notable example, if someone needs to search or
edit a large single-line JSON file, longlines.el currently sounds no
worse, and possibly better, than auto-narrow-mode, because it doesn't
disable font-lock and doesn't narrow the buffer, thus cannot affect
Lisp hooks and programs that aren't prepared for this narrowing.
Other solutions we have each one has advantages in other situations.

IOW, we can only consider valid use cases as "unimportant" or "rare
enough" if we are implementing yet another way of trading editing and
text-processing capabilities and features for responsiveness.  The
complete solution, by contrast, should cover _all_ the valid uses, and
should allow the user to use Emacs _as_usual_, without losing any
features, when files have very long lines.  (Here "valid" means
basically any useful Lisp program that doesn't intentionally crash or
infloop.)

If we cannot or don't intend to provide such a complete solution, we
should have several ones, and let the users choose what is best for
them in each situation.