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 9:27 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > > The normal/recommended call looks like:
> > > 
> > > (let ((cseq '("alpha" "beta" "gamma" "delta" "epsilon" "zeta" "eta")))
> > > (completing-read (format-prompt "Grapheme" "alpha")
> > > cseq nil t nil nil "alpha"))
> > > 
> > > [ Yes, it's a bit cumbersome: hysterical raisins :-( ] - Stefan
> > 
> > Correct. The solution involves an unwieldy parameter configurations, and possibly
> > using convoluted workarounds to achieve the desired behavior. This scenario implies
> > that using the function as intended requires a level of effort, understanding, and
> > manipulation that goes beyond direct usage.
> 
> 
> Agreed. That argues in favor of introducing a new function. But that
> new function would be so similar to `completing-read` that it will lead
> to users wondering when to use which or why there are two unless we mark
> `completing-read` as obsolete, which would in turn cause a lot of
> warnings in a lot of packages and code churn.
> 
> So, we've been hesitating to make this change for a while, not sure
> which choice is least bad.
> 
> But at this point do you consider the behavior of
> 
> (let ((cseq '("alpha" "beta" "gamma" "delta" "epsilon" "zeta" "eta")))
> (completing-read (format-prompt "Grapheme" "alpha")
> cseq nil t nil nil "alpha"))
> 
> to be a good solution for your original problem?

It is not, because the intention is on prefilling the minibuffer with "alpha"  
rather than considering "alpha" as DEF.  

It appears that the maintainers might not be prioritizing the initial intention
of prefilling the minibuffer.  Currently, their emphasis seems to be on encouraging 
developers to either utilize the "DEF" approach or actively discourage the use of 
"INITIAL".  But, I haven't come across a clear and well-founded reasoning behind 
these shifts in approach.

Let just remember that COLLECTION might already have been defined somewhere else
according to some arrangement rule regarding the order of its entries.  Rearranging
the actual order of elements in collection just to fit the limited requirements
of completing-read is not to be considered good function design.  Apart from the 
reality that rearranging the entries in COLLECTION might be difficult or even
impossible to achieve.  The example I show is straightforward in that you can see 
the entries and you can easily arrange them as you had suggested earlier
with

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

But this is only easily done only when collection is actually being constructed
in-place via the 'let' clause.   But once COLLECTION starts getting imported
from somewhere else (via a call to same other function for instance), your suggested
solution is impossible to achieve. 
 
> [ BTW, to me the main benefit of a new function is that we could try
> and make it so that the user can choose between a UI where the default
> is not inserted in the initial minibuffer (as in the above code), or
> one where it is (presumably pre-selected so you can delete it with
> a simple DEL), as is common in many other applications. ] - Stefan

I am neutral towards have two functions or a single one.

One can be considered as enhancing the functionaity of the other, leaving
the former for simpler use cases (and to conform in regards to backward 
compatibility) - if sensible names can be made up such that no confusion 
about their use can arise.  

Failing that, one can have a single function, where the coder can clearly
specify the way in which he wants it used.  Currently the design is for
completing-read to determine by itself the strategy it should use, without
giving the coder actual control on how completing-read should behave when 
one is faced with certain implementational circumstances where workarounds
are burdens to avoid rather than embrace.