GNU bug report logs -
#65459
completing-read INITIAL-VALUE unaware of COLLECTION and REQUIRE-MATCH
Previous Next
Full log
Message #53 received at 65459 <at> debbugs.gnu.org (full text, mbox):
> 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
This bug report was last modified 1 year and 289 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.