On 10/3/2024 11:28 PM, Eli Zaretskii wrote:
> A.k.a. (bobp), right?  Since point is already at position.

Fixed. Since point is at position, I've modified everything in the 
function to use (point). That way, there's no risk of confusion if 
someone looks at this years later and wonders why some parts use "point" 
while others use "position".

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

I think in addition to that, it's allowed if the display property has 
changed at the beginning (or end) of the line. For example, if I were to 
use the 'image' spec to render an image in-line with some other text, 
then 'visual-wrap-prefix-mode' can set the wrap-prefix as usual with no 
issues. The simpler case is when the image is at the end:

   * Here is some text. [IMG]

That should get the wrap prefix. The reverse is also true, though it's 
more complex:

   [IMG] Here is some text.

A mode that does something like that should set 'adaptive-fill-function' 
to handle this case and return an appropriate fill-prefix. Then 
'visual-wrap-prefix-mode' would do the right thing. For example, maybe 
EWW could do this to support images for bullet points (I'm not sure this 
is something we *actually* want to do in EWW, but hopefully it serves as 
an example.)

To be on the safe side, I'm only marking 'height' and 'raise' as safe 
for now, but adding new safe specs should just be a matter of putting 
them in the list.