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: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>, 55205 <at> debbugs.gnu.org
Subject: bug#55205: 28.1.50; completion--replace illegally mutates completion candidates
Date: Mon, 2 May 2022 12:17:53 +0200

On 5/2/22 12:07, Lars Ingebrigtsen wrote:
> Daniel Mendler <mail <at> daniel-mendler.de> writes:
> 
>> Okay, but that's not a good idea since then the return value of
>> completing-read will differ depending on the way the user performed
>> selection or completion. The caller of completing-read will have to
>> handle return values without text properties anyway so nothing is won by
>> returning strings with text properties only *sometimes*.
> 
> Of course there's something won by returning the exact, non-stripped
> string when the user has selected one of the choices.  It tells us
> exactly that -- that the user has chosen between one of the (textually)
> identical versions.

Okay, if you want that, then you can consider that an advantage. I still
argue that this will lead to more bugs in the end since people will
start to rely on text properties being always available. This is
particularly problematic for completion UIs like Icomplete/Vertico/Ivy,
which always select. These UIs will then always return propertized text
strings and as a consequence users, package developers will assume that
text properties are always there, while normal default completion (when
not selecting via the Completions buffer) will never return propertized
strings.

Anyway, I think I cannot convince you here. As I said, I changed my
opinion on this topic after I gained more experience with writing
completion UIs (Vertico, Corfu and I contributed to others) and
completion functions. Originally I also wanted propertized strings but
now I believe it is better to go with the more restricted API, which
behaves uniformly over all scenarios.

Daniel

Previous Next

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