[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: completing-read depricated initial-input

From: Jean Louis
Subject: Re: completing-read depricated initial-input
Date: Fri, 24 Jun 2022 10:08:12 +0300
User-agent: Mutt/+ () (2022-05-21)

* Christopher Dimech <> [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.


Take action in Free Software Foundation campaigns:

In support of Richard M. Stallman

reply via email to

[Prev in Thread] Current Thread [Next in Thread]