GNU bug report logs - #65348
INITIAL-INPUT in completing-read repeats same entry twice consecutively

Previous Next

Full log

View this message in rfc822 format

From: Drew Adams <drew.adams <at> oracle.com>
To: Heime <heimeborgia <at> protonmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: "65348 <at> debbugs.gnu.org" <65348 <at> debbugs.gnu.org>
Subject: bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively
Date: Fri, 18 Aug 2023 01:47:37 +0000

> > Which is why the ELisp manual says:
> >
> > The argument INITIAL is mostly deprecated; we recommend using a
> > non-‘nil’ value only in conjunction with specifying a cons cell for
> > HISTORY. *Note Initial Input::. For default input, use DEFAULT
> > instead.
> >
> > In any case, the fact that you see "boxplus" as the first suggestion
> > of the "future history" is because you both added it to COLLECTION and
> > set INITIAL to it. So showing it as the first suggestion is exactly
> > what completing-read should do in this case.
> >
> > This is not a bug, and so I'm closing it.
> 
> So one is not supposed to have the value in COLLECTION if it has been
> specified
> in INITIAL ?
> 
> I find using INITIAL quite useful because the user sees something filled
> up. What is one to do instead ?

I think it's only recently that Someone(TM)
thought it was a good idea to add all of
COLLECTION to the "future history".

Previously, the designer of a particular call
to `completing-read' could control the future
history by explicitly giving it what it was
originally designed to have: a specific DEFAULT
value or values.  The designer controlled not
only the members of the future history but
their order.  Alas, no more.

IMO the blind, unavoidable, automatic addition
of COLLECTION to the future history should be
expunged as a misguided misfeature. 

Previous Next

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