bug#56393: Actually fix the long lines display bug

[Eli Zaretskii]

> Cc: larsi@gnus.org, 56393@debbugs.gnu.org
> Date: Thu, 07 Jul 2022 13:10:49 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> I don't yet have a good idea about where to check whether "narrowing"
> is necessary for commands like C-n and C-v, but maybe look where I set
> the display_working_on_window_p flag as guideline.  Another idea would
> be to use those new members in 'struct window', but then (a) it is
> less clear when to reset them, and (b) some commands might go far
> away, thus making those values no longer pertinent.

After some more thinking about this, I think I do now have an idea how
to tackle command that employ the display code.

I see that you decided to produce the "restriction" in init_iterator,
which would, of course, work, but IMO it has a disadvantage:
init_iterator is called a lot, so computing the "restriction" in it
should be very fast.  Your current implementation _is_ fast, but AFAIU
its result is that we _always_ restrict the display code from seeing
the entire buffer, even if there are no long lines in it, which I
think is unnecessary.  The original implementation only did that when
it detected a long line, and I think we should keep it that way,
because the "restriction" will inevitably have some negative effects,
however minor, on what we display.

My proposal is to calculate the "restriction" in start_display.  That
function is called by all the commands/functions that use the display
code outside of redisplay proper.  (I think one or two such places
call init_iterator directly, but we can either handle them specially
or change them to use start_display.)  In addition, to prevent even
start_display doing more than necessary, redisplay_window should
compute the restriction for the window that is about to be
redisplayed, and store the values in 'struct window'; then
init_iterator, if called inside redisplay, will then simply reuse
those values, and start_display will refrain from computing them anew.
(To know whether some code is invoked by redisplay, test the value of
the global variable redisplaying_p.)  This way, we could make the
"restriction" smarter, and only apply it when needed.  Another
advantage is that this way the "restriction" will be the same for all
the code that is called by redisplay_window, directly or indirectly,
which I think is safer than having different "restrictions" computed
by different functions.