Re: completing-read depricated initial-input

[Jean Louis <bugs@gnu.support>]

* Christopher Dimech <dimech@gmx.com> [2022-06-24 01:11]:
> 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. 

How I understand the "default" is that it should be the value
that function gives as result in case when user does not write
anything else, hits enter.

However, it does not work this way with `read-from-minibuffer',
so I will file bug report.

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

However, in this function it does work the expected way:

(completing-read "Your name: " '("Jean" "Emmanuel" "Adebayo") nil nil nil nil "Jean") ⇒ "Jean"

(completing-read "Your name: " '("Jean" "Emmanuel" "Adebayo") nil nil nil nil "Adebayo") ⇒ "Adebayo"

So I have filed bug report today, as that is not consistent behavior.

Initial input is something else, that is something I wish to
see there in front of me, ready to be chosen by pressing enter.

Those are totally different events. 

1) I maybe do not want to show any initial input, but if I press
   enter, I need my default

2) I maybe want to show the initial input, but if I delete it and
   press enter with empty string, I still need my default, which may
   be different from initial input.

For me it would be rather damaging to remove initial input as I do
work with it often, there are people employed working with it, it
would affect the business.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/