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).

This means that when 'visual-wrap-prefix-mode' sees the start of a 
replacing-display-property[1], we know we shouldn't interfere with the 
'eq'-ness of that run of text, so we move past it to the first position 
that's not 'eq' to the start. If you like, we treat the 
text-to-be-replaced as atomic, since (I think) that's roughly what 
xdisp.c does too.

[1] Technically, the visual-wrap code avoids adding properties to some 
non-replacing properties too, but since "do nothing" should always be 
safe, that shouldn't be a problem. (It could result in some text not 
having a wrap-prefix when we'd like it too, but we can always add new 
"safe" display specs if someone notices an issue; I wanted to err on the 
side of caution with what we consider safe.)