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

Sent with Proton Mail secure email.

------- Original Message -------
On Friday, August 25th, 2023 at 4:45 AM, Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> wrote:


> > > > 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?
> > 
> > There purpose of INITIAL has always been about prefilling the minibuffer.
> > No other 'completing-read' functionality can do such a thing. DEF has
> > always served a different purpose. For some reason that I cannot understand,
> > most of the communications I have try to persuade me to set INITIAL to nil.
> > INITIAL had a purpose, which under certain circumstances has implications
> > to the way COLLECTION is constructed and used. Rather than fixing the
> > difficulties for certain cases, the answer has always been the same, put
> > INITIAL to nil and just don't use it, and use DEF if you want. Even though
> > Default Settings and Minibuffer Prefilling result in two completely distinct
> > behaviours.
> 
> 
> My question is not about INITIAL-INPUT but about the behavior that the
> user sees: why do you want the users of your code to see a minibuffer
> that is prefilled rather than one whose content is initially empty?
> 
> That question is not rhetorical. There can be many different perfectly
> valid answers. Depending on that answer, the best way to code it can be
> quite different, tho.

I was planning something like for 'read-file-name' where one can expect 
that the initial input will very likely be the part the user will end up
typing, otherwise they can quickly do a simple cycling to see the possibilities.
 
> > > That's partly why I've asked about a concrete example showing the wider
> > > context :-) - Stefan
> > 
> > I am working on an Emacs org library for archeological investigations where
> > field practitioners can insert specific org templates detailing the progress
> > of excavations and finds. Each phase is categorised.
> > 
> > For instance
> > 
> > "Physical Analysis" "Chronological Dating" "Composition and Provenance" "Isotope Analysis"
> > 
> > And there exists a certain order. It would be difficult to change
> > that order on-the-fly just to make 'completing-read' happy. With each
> > exists specific templates that practitioners can introduce and
> > elaborate. Once certain aspects are completed, the previous
> > categorisations would be skipped, because they would no longer be
> > relevant. What gets shown is then directed towards improving
> > productivity, particularly when tight deadlines are imposed.
> 
> So, IIUC, you have a `completing-read` call asking them which template
> to insert, and you want to order the set of completions based on
> knowledge of the stage at which they are?

No ordering actually happens, a particular element in collection is used
to prefill the minibuffer entry and consecutive elements in simple 
cycling continue through the next stages.

The ordering in 

"Physical Analysis" "Chronological Dating" "Composition and Provenance" "Isotope Analysis"

is an order in the operational flow, and it would not be possible to apply any alphabetical
type of sorting.  

> I suspect you'll want to use a COLLECTION that explicitly asks to not be
> (re)sorted and which you "manually" re-order before the call, so that
> the sort order you choose is obeyed not just by this specific cycling
> you're using but also for users who rely on different UIs.

Actually, tho order is only obeyed for the specific cycling I am using, but
users have the possibility to use a different UI such as the usual manipulation
possibilities provided by completing read.
 
> I don't see any part there that explains why the minibuffer needs to be
> prefilled, but that is usually handled separately from the
> completions anyway. - Stefan

Then my conclusion is that the introduction of INITIAL for 'completing-read'
was a mistake.  That completing-read should only be about completion.  And that
prefilling the minibuffer should involve a separate function call.

From my interactions, it seems evident that we cannot get rid of INITIAL either,
and we are stuck with it.  And the reason for discouraging its use.  I am not sure
whether simple cycling and completion should be provided by a single function, 
although the capability of managing both would be very powerful.