GNU bug report logs - #76018
31.0.50; wrap-prefix properties from visual-wrap-prefix-mode proliferate

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jim Porter <jporterbugs <at> gmail.com>
Cc: luangruo <at> yahoo.com, 76018 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, kevin.legouguec <at> gmail.com
Subject: bug#76018: 31.0.50; wrap-prefix properties from visual-wrap-prefix-mode proliferate
Date: Sat, 31 May 2025 10:20:09 +0300

> Date: Fri, 30 May 2025 21:59:40 -0700
> Cc: luangruo <at> yahoo.com, 76018 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca,
>  kevin.legouguec <at> gmail.com
> From: Jim Porter <jporterbugs <at> gmail.com>
> 
> >> +If any text in the region has any other @code{display} properties, those
> >> +properties are retained.  For instance:
> > 
> > I think this (and the doc string of the function) is confusing,
> > because it is not clear what you mean by "'display' property PROP" vs
> > "other 'display' properties".  The example seems to suggest that PROP
> > is the car of the value of the 'display' property.  Tha tis, if the
> > property's value is '(space . PROPS)', then one needs to call this
> > function with 'space' as PROP, and the same for 'image' etc.  This
> > should be spelled out.
> 
> This is something that confuses me too. Is there a term we should use 
> for 'space' or 'image'? I know that '(space . PROPS)' is a "display 
> specification", and the 'display' text property can be a display 
> specification (or a list or vector of display specs). But it seems 
> there's no term for the car of the display spec. Maybe "the car of a 
> display spec" would work? Currently, the manual entry for 
> 'get-display-property' calls it a "specific display property" or just 
> "'display' property". I'm open to suggestions here.

Yes, "the car of the display spec" will work, I think.

> >   . what about 'display' property whose value is '((margin nil) STRING)'?
> 
> This should work fine, since we compare the car of the display spec 
> using 'equal'.

So that kind of property is also not supported?

> >> +(defun add-display-text-property (start end prop value
> >> +                                        &optional object)
> >> +  "Add display property PROP with VALUE to the text from START to END.
> >> +If any text in the region has a non-nil `display' property, those
> >> +properties are retained.
> > 
> > But they could be split into two separate stretches, right?
> 
> Not for this function ('add-display-text-property'), but for 
> 'remove-display-text-property', this could split the property in two: 
> one before and one after the specified region. That's similar to 
> 'remove-text-properties'. I tried to show the details of all that in the 
> manual entry.

I think the add function could also split.  Consider text which has
some display property between positions A and B, and then you call
add-display-text-property to add a display property with another spec
between START > A and END < B.  The result will be text with the
original display property between A and START, the new property plus
the old one between A and END, and a copy of the original property
between END and B.  Right?

Thanks.

Previous Next

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