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

Previous Next

Full log

Message #131 received at 55205 <at> debbugs.gnu.org (full text, mbox):

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

On 5/2/22 18:34, Stefan Monnier wrote:
>> Completion takes text typed by the user and produces strings that the
>> user could possibly mean by typing what he/she typed.  Some part(s) of
>> the candidates can legitimately come from what the user typed, some
>> other part(s) could be invented by the completion machinery more or
>> less out of thin air.  Why should anyone expect this meat-grinder to
>> refrain from destructively modifying any of the involved strings?
> 
> Because the overwhelming majority of strings are never modified.
> It's very unusual to modify a string by side effect (as opposed to
> creating a new string object via `concat`, `substring`, ...).
> This is true in most languages, AFAICT, but it's definitely true in
> ELisp.

One should add that *by definition* of the completion API, mutations of
the supplied candidate strings don't take place. For example you can run
completion on strings from the obarray:

(completing-read "Symbol: " obarray)

It would be quite harmful if the symbol names are destroyed in the
process. I don't see the completion API as a meat-grinder. It is all
quite well-defined.

Daniel

Previous Next

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