GNU bug report logs - #65459
completing-read INITIAL-VALUE unaware of COLLECTION and REQUIRE-MATCH

Previous Next

Full log

Message #62 received at 65459 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Heime <heimeborgia <at> protonmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 65459 <at> debbugs.gnu.org
Subject: Re: bug#65459: completing-read INITIAL-VALUE unaware of COLLECTION
 and REQUIRE-MATCH
Date: Thu, 24 Aug 2023 12:45:53 -0400

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

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

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.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.