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

Previous Next

Full log

View this message in rfc822 format

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

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

Previous Next

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