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

[Daniel Mendler]

On 5/1/22 19:26, Lars Ingebrigtsen wrote:
>>> I don't remember why we're doing that, but I seem to vaguely recall that
>>> there's a reason...  Anybody?
>>
>> I'm pretty sure there's a reason, and I'm pretty sure this reason is
>> "sloppiness".  I blame the author of commit 1d00653d9e (and the author
>> of commit 14486c44 might be considered as an accessory to the crime).
> 
> Is there no way to let the text properties survive completion?  Because
> that's also come up more than a few times.

Just to clarify, the question if completion should preserve candidate
text properties is a different one than the one which led to this bug
report. There is minibuffer-allow-text-properties as Stefan pointed out.
This lets completion UIs preserve text properties in principle when
returning from the minibuffer.

However when completing a string in the minibuffer, the completed string
can also be typed by the user and as such won't have the text properties
attached in the first place. The completion UI would then have to lookup
the input string in the list of propertized candidate strings. Of course
this makes only sense for REQUIRE-MATCH non-nil.

One motivation for text property preservation is the disambiguation of
equal strings. I argue that equal candidate strings are not a good idea
since the user has no way to distinguish them TAB completing. However
disambiguation (and preserving object identity) would be possible in
completion UIs with a selection mechanism (clicking in the Completions
buffer, or selecting a marked candidate in Icomplete/Vertico/Ivy/...).
It boils down to the question if we treat completion as step-by-step
text completion (by pressing TAB) or as a selection process of a
candidate. Due to the way these different UIs behave, selection vs
completion is a gray zone.

About a year ago I was also in the camp of people who wanted to preserve
text properties (because of disambiguation, to be able to attach
metadata and because object identity). I asked once one the mailing list
about this. But I've changed my opinion since then. Not preserving text
properties for completion seems like the better approach since then we
make fewer assumptions how the candidate materializes, either via
selection, via manual input or via TAB-completion. For unique candidate
strings and REQUIRE-MATCH non-nil, looking up metadata in a hash table
or an alist after the return of completing-read is only a small
inconvenience.

Daniel