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

[Drew Adams <drew.adams@oracle.com>]

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