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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: mail <at> daniel-mendler.de, larsi <at> gnus.org, 55205 <at> debbugs.gnu.org
Subject: Re: bug#55205: 28.1.50; completion--replace illegally mutates
 completion candidates
Date: Mon, 02 May 2022 19:43:48 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: larsi <at> gnus.org,  mail <at> daniel-mendler.de,  55205 <at> debbugs.gnu.org
> Date: Mon, 02 May 2022 12:34:28 -0400
> 
> > I have no idea.  The way you present this is waaay above my level of
> > understanding.
> >
> > 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.

I have no doubt that in most cases there's no modification of the
original strings.  However, AFAIU the discussion was about not letting
that happen, ever, and that I cannot understand.

IOW, I'm saying that people who want to see all the strings immutable,
all the time, have wrong expectations _in_principle_, even though in
most cases they will probably get what they want.

Previous Next

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