Re: completing-read depricated initial-input

[Emanuel Berg]

Jean Louis wrote:

> (read-from-minibuffer "Your name: " nil nil nil nil "Jean")

Holy cow, there's no need to hard code that! What if you were
to change your name (nom de guerre if you wish) for romantic
and/or conspiratorial reasons? Use `user-full-name'
instead ...

(BTW 4 nil in a row. How many do you need to strike
the jackpot?)

>> Inserting default would make sense. We should not continue
>> with the initial-value name then. Stating that DEF will be
>> displayed as first instance. Making things smoother and
>> clearer to understand.
>
> I do not find it so. I do not say how function works, but
> I wish to say what I expect as user.

We have been thinking of it in very practical terms so far.

I already asked, what concept is the initial value? I'm not
aware of any such concept in this context. One can think of
several UIs (including GUIs) where the initial value has been
inserted to communicate the default value, and enable -
transparently, even - for the user to submit this value.
In that sense, it isn't that bad: the default value is shown
loud and clear, it can be edited and when its submitted this
happens with the same method so no extras in terms of
technology at that end.

However ...

We don't want that for the default value so all that doesn't
matter anymore (or to us).

If we look at it from even further away the initial value
makes even less sense. "Why is the computer putting stuff
there? It's the area where the human user should put stuff."

So in general it doesn't make sense, specifically it _could_
make sense but it doesn't since we have another, better method
for that.

There is only one use case (completion with a common prefix)
however that can either be automated _or_ solved with the
default method _and_ relying on completion to navigate huge
search spaces of similar members, that's a poor situation to
begin with, maybe it gets mildly better with completion but
that's obviously nothing to base general policy on.

-- 
underground experts united
https://dataswamp.org/~incal