GNU bug report logs - #73600
31.0.50; Visual wrap prefix mode and image display

Previous Next

Package: emacs;

Reported by: Gautier Ponsinet <gautier <at> gautierponsinet.xyz>

Date: Wed, 2 Oct 2024 15:21:02 UTC

Severity: normal

Found in version 31.0.50

Done: Jim Porter <jporterbugs <at> gmail.com>

Full log


View this message in rfc822 format

From: Jim Porter <jporterbugs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 73600 <at> debbugs.gnu.org, gautier <at> gautierponsinet.xyz
Subject: bug#73600: 31.0.50; Visual wrap prefix mode and image display
Date: Sun, 13 Oct 2024 10:38:09 -0700
[Message part 1 (text/plain, inline)]
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.)
[0001-Don-t-add-visual-wrap-prefix-properties-to-unsafe-mu.patch (text/plain, attachment)]

This bug report was last modified 19 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.