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

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

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

Could you explain why this is important in your case?

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

Not sure what you mean by "shifts".  AFAIK this behavior has been with
Emacs "forever": most minibuffers start empty (but with an associated
default value) rather than starting with an initial value.

This originally comes presumably from the absence of
`transient-mark-mode` (or associated visual highlighting, both of which
were introduced in Emacs-19) which means that it was annoying having to
erase "alpha" before you can type "beta".

Starting with a non-empty minibuffer does happen occasionally, most
importantly for `read-file-name` where we do expect that this initial
input will very likely be a part of the name the user will end up
typing, so its rare that the users need to erase it before they can type
the file name they want.

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

That's partly why I've asked about a concrete example showing the wider
context :-)


        Stefan