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

[Heime via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

------- Original Message -------
On Thursday, August 24th, 2023 at 1:07 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:


> > 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).

I am aware and have no problem with the points mentioned - structured completion and
INITIAL-INPUT not being a valid end point with regards to REQUIRE-MATCH as 't'.
 
> > 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".

Consider simple cycling through completion options using the down arrow key (<down>) in 
the completing-read function.  When using completing-read, you can cycle through the 
available completion options by pressing the 'down' arrow key.

Consider

  (interactive
    (let ( (cseq '("alpha" "beta" "gamma" "delta" "epsilon" "zeta" "eta")) )
      (list
        (completing-read "Grapheme: " cseq nil t "alpha")) ))

I have no problem with possibility of having INITIAL not in COLLECTION.
But, suppose that I pre-insert the first element in collection as INITIAL
value in minibuffer.
 
Then, repeatedly hit <down>.  You get

alpha alpha beta gamma delta epsilon zeta eta alpha beta gamma and-so-on

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

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

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

> 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?

As a coder and after some tests mimicking a user using only simple cycling. 
 
> > 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

My school of thought is always allow the programmer to define how much freedom
he intends to give the completion UI.