Subject: bug#65459: completing-read INITIAL-VALUE unaware of COLLECTION and REQUIRE-MATCH

From: Stefan Monnier <[email-masked]>
Date: Wed, 23 Aug 2023 12:05:35 -0400

> Then, repeatedly hit <down>.  You get
>
> alpha alpha beta gamma delta epsilon zeta eta alpha beta gamma and-so-on

Ah, OK, yes, that sounds like a problem (one I've heard before).
I think it's a problem in the cycling code rather than in INITIAL-VALUE
or COLLECTION.  E.g. the same problem occurs if the initial input is
empty and the user types `alpha C-n`.

> You do actually get that the consecutive entries appearing in the
> minibuffer have direct correspondence to to order found in COLLECTION.

For that form of cycling, apparently so, yes.  I don't categorize it as
"completion" so I haven't looked very closely at that code :-)
There are other ways to do cycling which use a different ordering.

The cycling through completions via `next-line-or-history-element` is
not very configurable, AFAICT.

> Once INITIAL is inserted, I cannot instruct completing-read to continue
> sequentially starting from a particular element.

Indeed.

> For instance, I cannot get the following result when using simple cycling 
> through collection options when repeatedly hitting the <down> key.
>
> To achieve
>
> alpha epsilon zeta eta alpha beta gamma delta epsilon and-so-on

Could you give a bit more context about why/where you'd want to do that
so I can better imagine how to attack the problem?

Hopefully it would explain why you want "alpha epsilon ..." first but
"alpha beta .." later.  Also for such uses of `completing-read` we
usually recommend against a non-nil value for INITIAL-INPUT, so that
context should try to explain why you use "alpha" as INITIAL-INPUT.

        Stefan