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

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I'm a strong proponent of "different completions should be selectable by
> different strings", for the kinds of reasons exposed by Daniel: it makes
> it possible to use more UI styles than just selection (and it interacts
> better with other things like elimination of duplicates).

If we have completions that are textually different, then that's no
problem, of course.  But requiring the callers to construct strings that
differ in artificial ways seems less than optimal.

> But FWIW, that is not a reason to force throwing away the text
> properties (IOW the act of stripping the text properties is not
> a feature of the code).
>
> E.g. I'd recommend you always include the movie's unique ID in the
> completions, probably covered/hidden by the movie's poster (so the ugly
> ID doesn't show up).  And when the user selects that entry it would make
> a lot of sense to keep displaying the poster.

I think that's what people normally do in these circumstances, but it's
a pretty confusing interface.  The completions show up looking
identical, but with hidden text that you can complete with.

>> If I remember correctly, I ended up copying most of the completion
>> machinery into the package just to avoid the stripping.
>
> We should fix the code so it's not necessary.

Which brings me back to my original question.  😀  Why are we stripping
text properties?  Is this to fix some bug or something?

I.e., if we add an interface to allow completion to not strip text
properties, is that going to lead to bugs?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no