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

[Stefan Monnier]

> How can we describe it - primitive - then.  What lots am I missing about
> the behaviour of INITIAL-VALUE being independent about the state of the
> other variables ?

I can't really answer that because I don't fully understand what it is
you're trying to do and feel that you can't do with this API.

Maybe you're missing what other people usually miss:
`completing-read` is also used for completion of things that have
structure, like file-names, and where the INITIAL-INPUT may be a good
starting point for the user while not being a valid end point
(i.e. a choice rejected by REQUIRE-MATCH).

> And that entries in collection always start from index
> zero when cycling is used.

Don't know what you mean by that.  Could you clarify?

By and large the COLLECTION argument is treated as a *set*, i.e. without
any ordering.  Instead, the ordering is chosen by the UI (i.e. the
completion code) and can depend on various user config choices, so
I don't know what you mean by "always start from index zero".

I'm also not sure what you mean by "when cycling is used".  Are you
referring to the first choice offered by `minibuffer-complete` when
`completion-cycle-threshold` is set to something like t?

> I have found its capability limited, having actually used it.

Are you talking about "used it" as an end-user or as a coder?

> I expected that as the functionalities get enhanced, some deficiencies
> also get pumped up.  Giving more control to the programmer about what
> gets displayed in the minibuffer.

The intention is to try and make room for 3 parts:

- what the programmer provides to `completing-read`.
- what the end-user sees.
- between those two, the specific completion UI chosen by the end-user.

So indeed, we don't want to offer too much control to the programmer who
calls `completing-read`, so as to give more freedom to the
completion UI.


        Stefan