bug#55205: 28.1.50; completion--replace illegally mutates completion candidates

[Daniel Mendler <mail@daniel-mendler.de>]

On 5/4/22 10:24, Daniel Mendler wrote:
> 
> 
> On 5/4/22 09:48, Lars Ingebrigtsen wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>
>>>> But I still have no idea why we're stripping text properties in the
>>>> first place, so could you please explain that?
>>>
>>> It depends where.  In `completion--replace` it's explained in the
>>> comment:
>>>
>>>     ;; The properties on `newtext' include things like the
>>>     ;; `completions-first-difference' face, which we don't want to
>>>     ;; include upon insertion.
>>
>> So it's really about stripping modifications that completion has already
>> done to the strings?  Well, that seems like an easy enough problem to
>> deal with -- just remove those, and leave the rest of the text
>> properties alone.
> 
> I don't understand where the discussion is going. The bug has been fixed
> by copying the string, ensuring that any original candidate string stays
> unchanged. Just stripping the properties which were supposedly added by
> completion is not a good solution since the original candidate string
> could already come with exactly these properties.

I think my last mail missed the point. `completion--replace` is supposed
to strip *all properties* since we are inserting the completed text in
the destination buffer. At this point the inserted/replaced text is to
be treated like user input and shouldn't carry any text properties,
neither text properties produced by completion, nor text properties
which were attached originally to the candidate strings.

Daniel