bug#56393: Actually fix the long lines display bug

[Eli Zaretskii]

> Date: Thu, 07 Jul 2022 08:23:11 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, 56393@debbugs.gnu.org
> 
> > C-p takes an inordinate amount of time in those cases because it calls 
> > functions of the display engine (see vertical-motion).  Limiting the 
> > display code to some small enough region of the buffer will speed that 
> > up as well, since it's the same code in both cases.  The somewhat tricky 
> > part with the likes of C-p is where and how to compute the restriction.
> >
> 
> Okay.  Can I try to do this myself, or are you already working on it, if 
> not already polishing your code?

I'm not working on this (unless you call this discussion and trying
the branch "work" ;-).

If you want to try this, here are some thoughts which may or may not
prove useful:

  . for actual redisplay, the natural place for checking whether we
    need to "narrow" is at the beginning of redisplay_window, where
    you can check the window's buffer; this might need to be rechecked
    in the few places (maybe just one) where redisplay moves point
  . to compute a good value for "narrowing", multiply the number of
    rows of the window's glyph matrix by the number of glyphs in each
    row, then by some small factor (like 2 or 3)
  . the way to "narrow" for display code only is to replace BEGV and
    ZV with new macros, say DBEGV and DZV, which look at separate
    variables, possibly new members in 'struct window', if those are
    set; when the above-mentioned check determines that "narrowing" is
    needed, set them accordingly
  . a good place to reset these new members of 'struct window' is in
    mark_window_display_accurate_1, when the window's display is
    marked as "accurate"
  . various calls to the likes of Fnext_single_property_change in the
    display code will need to specify explicit limits for the search,
    using DBEGV and DZV, instead of falling back on BEGV and ZV that
    are already set

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.

Let me know if you need help with display code internals.

Thanks.