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

From: Eli Zaretskii <[email-masked]>
Date: Sun, 13 Oct 2024 21:51:33 +0300

> Date: Sun, 13 Oct 2024 10:38:09 -0700
> Cc: [email-masked], [email-masked]
> From: Jim Porter <[email-masked]>
> 
> On 10/12/2024 10:36 PM, Eli Zaretskii wrote:
> > Yes, this is what I had in mind, thanks.  But does
> > next-single-char-property-change really fit the bill?  What if you
> > have several overlapping 'display' properties, and in particular one
> > property "enclosed" in another?  Did you test such a scenario?
> 
> I had tested those manually and they worked (according to my 
> understanding of display properties, anyway). I've added some test cases 
> to that effect in the latest patch.
> 
> Just to make sure we're on the same page: my (admittedly limited) 
> understanding of xdisp.c is that, for replacing-display-properties, 
> Emacs determines the range of buffer text to replace by using 'eq' on 
> the 'display' property. So if you have an 'image' spec from positions 1 
> to 10, but add a 'height' spec from positions 3 to 4, Emacs will now 
> render the image three times: one each for the ranges [1, 3), [3, 4), 
> and [4, 10).

That is probably correct, at least in some cases, but why should we
rely on that for this purpose?  Isn't it more reliable and
future-proof to skip the entire span of the outermost "replacing"
display property, and never look at properties inside that text?  Does
it really matter for visual-wrap-prefix-mode to look inside?

IOW, I prefer simplicity of the logic to sophisticated design based on
what we actually see Emacs do in tricky cases, because time and again
I learned the hard way that my mental models of what actually happens
can be erroneous in the fine details.