GNU bug report logs - #55205
28.1.50; completion--replace illegally mutates completion candidates

Previous Next

Package: emacs;

Reported by: Daniel Mendler <mail <at> daniel-mendler.de>

Date: Sun, 1 May 2022 08:29:02 UTC

Severity: normal

Found in version 28.1.50

Done: Daniel Mendler <mail <at> daniel-mendler.de>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, Eli Zaretskii <eliz <at> gnu.org>, 55205 <at> debbugs.gnu.org
Subject: bug#55205: 28.1.50; completion--replace illegally mutates completion candidates
Date: Tue, 03 May 2022 12:13:36 +0200
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> The strings used for completions are the "identity" of each completion.
> so if there are two distinct completions, they should have
> distinct strings.  I don't see what's artificial about it.

The "are" there is doing a lot of work here.  :-)  In my use case, the
stringly representation is not the identity of the selection.

> Somehow the user (and the code) needs to be able to distinguish between
> the various identically named movies.  You do that with a poster image
> and I'm suggesting that this poster image should be covering some
> "unique" identification information.  I.e. something like:
>
>     (concat movie-name (propertize movie-id 'display movie-poster))

And that is the artificiality of it.  If you're on a web page listing
different items, and they have the same name, you don't see the web
designers putting made-up irrelevant characters into the link text --
they keep the identifying stuff hidden in the links.

> The rest of the discussion made me realize that maybe I misunderstood
> your question.  Are you talking about the stripping that takes places
> *during completion* (e.g. when clicking in *Completions*) or are you
> talking about the stripping that takes place just before returning the
> value of `completing-read`?  Some other?

I don't remember any more -- I only know that the text properties are
stripped at some point.

>> I.e., if we add an interface to allow completion to not strip text
>> properties, is that going to lead to bugs?
>
> What do you mean by "interface"?  You mean a UI or an API?
> For an API it would probably lead to this API being virtually unusable
> for some UIs.

I was being vague, because I don't know how we'd specify "don't strip
the text properties".  Probably like how we specify affixation functions
and all the rest.

But I still have no idea why we're stripping text properties in the
first place, so could you please explain that?

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




This bug report was last modified 232 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.