Re: RE: [External] : completing-read depricated initial-input

[Christopher Dimech <dimech@gmx.com>]

> Sent: Saturday, June 25, 2022 at 2:30 AM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Emanuel Berg" <incal@dataswamp.org>, "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> Subject: RE: [External] : Re: completing-read depricated initial-input
>
> > I already asked, what concept is the initial value?
> ...
> > "Why is the computer putting stuff there?  It's
> > the area where the human user should put stuff."
> ...
> > There is only one use case (completion with a
> > common prefix)
>
> Please read (again?) what others have written.
>
> First, it's initial _input_, not initial value.  It's
> about prefilling the minibuffer with particular text,
> which you can use any way you like (e.g. edit it).
>
> A common prefix is only one such use case.  (For one
> thing, prefix completion isn't all there is nowadays.)
>
> As the arg to `completing-read', `read-from-minibuffer',
> `read-string', `read-buffer', `read-minibuffer', etc.,
> it's unrelated to any default value.  (More precisely,
> it's not _necessarily_ related.)
>
> There's no reason it shouldn't be possible to provide
> you an initial-input that's useful for editing, even
> one that might not be directly related to any default
> value.
> ___
>
> As for inserting the _default value_ (not the INIT arg)
> in the minibuffer automatically: a user might want that.
> You might not; others might.  This should be a user
> choice, not imposed one way or the other.
>
> As I said:
>
>   If you often want to use or edit the default value,
>   then consider setting `icicle-default-value' to
>   non-`nil' and non-`t' [to insert it in the minibuffer].
>
>   If you rarely do so, then consider using `nil' or `t'
>   [to not insert it].
>
> As one user, I'm in the former camp: I often want
> to use or edit the default value, and as a result I
> prefer that it be inserted automatically.
>
> That is, I prefer to hit a key to delete it, in the
> (fewer) cases where I don't want it, than to have to
> hit `M-n' to insert it, in the (more numerous) cases
> where I do want it (including to edit it, rather
> than just accept it as is).
>
> Remember that minibuffer reading is not always, or
> even usually, a must-match situation.  Even for
> completion, there's lax completion (REQUIRE-MATCH
> nil).
>
> With well-designed code a `completing-read' call
> with lax completion can nevertheless provide a
> helpful default value - e.g., one that I might want
> to edit slightly.
>
> Of course, a `completing-read' call that gives you
> a poor default value lessens the utility of using
> it, and so lessens the usefulness of inserting it.
>
> Again, this want-or-don't-want-DEF-inserted is akin
> to whether to use `delete-selection-mode'.  I do
> use that mode.  Users are different.
>
> And it's important, IMO, to have a single key to
> empty the minibuffer, regardless of where point is.
> In `icy-mode' that's `M-k', by default.  Vanilla
> Emacs still has no such key.  (Why not?)
>
> Neither (1) having to use `M-n' to insert the
> default, nor (2) having to use `M-k' to erase its
> automatic insertion, is super bothersome.  Each
> can make sense and be preferred by some users.
> That's all.
> ___
>
> Summary:
>
> 1. There are uses for an initial-input arg.
> 2. Automatic insertion of the default value can
>    be useful and preferred by some users.  Let
>    users choose.
> 3. Emacs shouldn't deprecate, let alone get rid
>    of, an initial-input arg for `completing-read'.
>    In fact, it should consider adding one for
>    some functions that don't have it - some of
>    the `read-*' functions, for example.

I fully support the summary as well.