bug#73600: 31.0.50; Visual wrap prefix mode and image display

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 3 Oct 2024 17:28:14 -0700
> Cc: 73600@debbugs.gnu.org, gautier@gautierponsinet.xyz
> From: Jim Porter <jporterbugs@gmail.com>
> 
> On 10/3/2024 3:59 AM, Eli Zaretskii wrote:
> > I think image-mode is just the tip of a very large iceberg, see above:
> > visual-wrap-prefix-mode currently doesn't correctly handle text
> > covered by display properties.  I think this bug was uncovered when we
> > removed on master a few artificial restrictions on min-width, such as
> > non-support for display and overlay strings.
> 
> How about something like this? With this patch, if the start of a line 
> is in the middle of a multi-line display spec, 'visual-wrap-prefix-mode' 
> won't add any new properties. That should prevent any unwanted interference.

Something like that, yes.  But unfortunately, it's more complicated,
see below.

> --- a/lisp/visual-wrap.el
> +++ b/lisp/visual-wrap.el
> @@ -117,7 +117,16 @@ visual-wrap--apply-to-line
>    "Apply visual-wrapping properties to the logical line starting at POSITION."
>    (save-excursion
>      (goto-char position)
> -    (when-let ((first-line-prefix (fill-match-adaptive-prefix))
> +    (when-let (;; Don't add wrapping properties if we're in the middle
> +               ;; of a multi-line display spec; it could be doing
> +               ;; absolutely anything, and we don't want to interfere.
> +               ;; (For example, this could be an image containing a
> +               ;; newline-byte being displayed in `image-mode'; see
> +               ;; bug#73600.)
> +               ((or (= position (point-min))
                       ^^^^^^^^^^^^^^^^^^^^^^^^
A.k.a. (bobp), right?  Since point is already at position.

> +                    (not (eq (get-char-property position 'display)
> +                             (get-char-property (1- position) 'display)))))

I think this is too radical.  There are 'display' properties that do
not replace the text: (space PROPS), (height HEIGHT), (raise FACT),
and a few others.  These should not prevent adding the wrapping
properties, I think.  The challenge is to detect the presence of
"allowed" properties and the absence of "forbidden" ones, since a
'display' property's spec could be a list or a vector of several
separate values.  So the code will need to look inside the list/vector
and examine each element.

We could also start with the above and document that lines that begin
with any 'display' property will not be visually aligned/wrapped --
maybe this is not a severe restriction in practice.