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

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

On 5/2/22 08:31, Stefan Monnier wrote:
> 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).
> 
> 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).

As I understood, it is somehow a consequence of the way completion is
implemented, it is a step-wise input process via
completion-try-completion. If I enter pifb TAB it is essentially the
same as if I entered package-install-from-buffer. There is not really a
candidate lookup going on, the UI only ever sees the (maybe even
partially completed) string returned by the completion backend.

There are two ways out:

- The completion UI could lookup the original candidate string in a
final step just before returning from the minibuffer. This could only
happen when REQUIRE-MATCH non-nil.

- We throw away the entire paradigm of completion and go with selection
only. But I think we would lose to much by doing that.

But again, since Lars asked this - text properties are not stripped,
they never materialize in the first place due to completion just being a
form of user input. (Technically they are stripped, but only to
normalize the resulting input in case some text properties make it through.)

Daniel