bug#56393: Actually fix the long lines display bug

[Eli Zaretskii]

> Date: Fri, 08 Jul 2022 21:41:49 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Gerd Möllmann <gerd.moellmann@gmail.com>, larsi@gnus.org, 
>     56393@debbugs.gnu.org
> 
> I reverted all commits on the feature branch, and started anew.  The 
> feature has now been moved into the bowels of the display engine, and it 
> works even better.

Thanks.  A few comments to what I see on the branch (apologies if
these are premature because you are still working on the code):

  . init_iterator is also called to display strings, and I'm not sure
    I understand what you intended to do in that case, since BEGV/ZV
    are not relevant to strings.
  . The WITH_NARROWED_BEGV macro is IMO awkward and not very
    convenient to use in C.  For starters, it cannot accommodate
    multi-line code, except via the 'do { ... } while(0);' kludge,
    which I think will make the code less readable.  It also should
    set up an unwind-protect handler, so that any non-local exit from
    the code will restore BEGV/ZV.  So I think it will be better to
    have two separate functions (and a third one to unwind).
  . You currently only apply the "restriction" in a few places where
    the code calls functions like find_newline_no_quit.  What about
    the rest of display code -- are you saying that it doesn't need to
    be "restricted"? or do you intend to add that in the future?  And
    what about restricting the Lisp code invoked via
    Vfontification_functions (i.e. jit-lock.el)?
  . Don't we want to "restrict" ZV as well?
  . I'm not sure the "restriction" should be computed relative to
    point: that might be OK for redisplaying a window, but for
    commands that use the display code the position with which we call
    init_iterator and start_display might be a better/safer
    alternative, because that position could be very far from point.
    In any case, get_narrowed_begv receives a pointer to a window, so
    I think it should use the window-point, not PT, which is the value
    of point in the current buffer.
  . The 10000 number should at least be a C macro if not a variable
    exposed to Lisp.
  . The maximum number of characters in a window could be more than
    just its width multiplied by its height, because the window could
    use smaller fonts than the default.  I think it is safer to use
    the dimensions of the window's glyph matrix for this, because
    there couldn't possibly be more characters in the window than the
    glyph matrix allows, and we always resize the matrix when we need
    to display more characters.