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

[Heime]

------- Original Message -------
On Friday, August 25th, 2023 at 1:36 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.
 
> > 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.

Right.  Because most minibuffers start empty (but with an associated
default value) rather than starting with an initial value, this particular
use of 'completing-read' in today considered to be the only way to use 
'completing-read'.  Something that is completely wrong because a particular
use case has now became dogma.  One cannot ever disregard the different feature
provided by INITIAL for those who want to use it. 
 
> 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.

Right.  Although it is customarily rare, INITIAL does actually have relevant
use cases.  It just happens that over time, additional use cases have cropped
up.  Rarity seams to have became a reason to discourage use of INITIAL.  Such
school of thought is seriously misguided.  
 
> > 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

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.  

Tight deadlines in archaeological field excavations arise from a variety of 
logistical and 
operational factors).  For instance, certain sites are threatened by 
construction or development
projects, with limited timeframes to excavate and document findings.  Some 
sites are at risk of
deterioration due to environmental factors (e.g. flooding, collapse), meaning 
that emergency 
excavations within short timeframes to salvage artifacts and information 
becomes necessary.

Such application should be concrete enough.