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

Previous Next

Full log

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

From: Christopher Dimech <dimech <at> gmx.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, "eliz <at> gnu.org" <eliz <at> gnu.org>,
 "heimeborgia <at> protonmail.com" <heimeborgia <at> protonmail.com>,
 "65348 <at> debbugs.gnu.org" <65348 <at> debbugs.gnu.org>
Subject: Re: RE: [External] :  bug#65348: INITIAL-INPUT in completing-read
 repeats same entry twice consecutively
Date: Mon, 21 Aug 2023 06:26:07 +0200

> Sent: Monday, August 21, 2023 at 12:25 PM
> From: "Drew Adams" <drew.adams <at> oracle.com>
> To: "Christopher Dimech" <dimech <at> gmx.com>, "Michael Heerdegen" <michael_heerdegen <at> web.de>
> Cc: "65348 <at> debbugs.gnu.org" <65348 <at> debbugs.gnu.org>, "eliz <at> gnu.org" <eliz <at> gnu.org>, "heimeborgia <at> protonmail.com" <heimeborgia <at> protonmail.com>
> Subject: RE: [External] : Re: bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively
>
> > I suggest that the capability of prefilling the minibuffer be reintroduced
> > for the new scheme as well.  Because from what I see, the deprecated parts
> > include a feature that will be automatically discarded under the new
> > scheme.
>
> I missed that memo completely!  What's the new scheme?

The new scheme of using history which automatically discarded
the capability of prefilling the minibuffer before cycling can
start.

> What is expected to be automatically discarded?  Where
> is the presentation/discussion of such a change?  Is
> it this bug thread?  (Why would it be in a bug thread?)

As INITIAL is obsolete, the capability of prefilling the
minibuffer entry would be missing.

> I hope we're not changing the longstanding arg list of
> `completing-read' (except perhaps to add more args,
> which might be debatable but excusable).

It is a problem.  We have been very happy adding more args for
new features, without taking serious consideration the resulting
confusion between old schemes and new schemes, resulting in numerous
recommendations.  The less recommendations on how to use a function
the better things will be to work with.

When deep changes happen, I prefer to keep the old as is,
and make a new function for significant changes that affect
the old functionality.

It does not happen regularly that new features are accessed in ways that
maintain clarity and avoids unnecessary complexity.

> Let's please keep this function backward-compatible.
> If you want something different, please add it as a
> separate function.

That's the whole point, and we should follow that route
as an important strategy for maintainers.

Previous Next

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