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

[Lars Ingebrigtsen]

Daniel Mendler <mail@daniel-mendler.de> writes:

> 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.

Ah, yes, I was thinking about the REQUIRE-MATCH case.

> 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.

I've got an imdb interface where I choose among different movies (some
with the same name) by putting the movie poster in the completion
string to disambiguate.  That's the first place I ran into the problem,
years ago (and it seems like people keep trying to do things like that,
and then giving up).

If I remember correctly, I ended up copying most of the completion
machinery into the package just to avoid the stripping.

(It's a somewhat marginal problem, since it's seldom there's several
movies with the same name in the same year, but it happens.  But you
could imagine the same issue when completing, say, names in an org, and
displaying pics of the people to disambiguate.)

> 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.

Hm, yes.

> 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.

Yes, but if the strings are identical (except for the text properties),
then that's not really an option.

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