[Top][All Lists]

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

Re: completing-read depricated initial-input

From: Tassilo Horn
Subject: Re: completing-read depricated initial-input
Date: Thu, 23 Jun 2022 13:26:13 +0200
User-agent: mu4e 1.7.28; emacs 29.0.50

Emanuel Berg <> writes:

>>>> Improved user experience?
>>> Why/how so?
>> You have to delete the initial input if it's not what you
>> want or if you want to see the other possibilities.
>> So basically all occurrences where INITIAL-INPUT is used as
>> a kind of default value are better handled with the
>> DEF argument.
> I know but ... why are you telling me this?

Because you've asked why/how not using INITIAL-INPUT with
completing-read has an improved user experience.

> IMO this is the best way of doing it:
> (let ((name "Danger"))
>   (read-string (format "name: [%s] " name) nil nil name) )

But it has nothing to do with completing-read.

>> The only places where I can see it's useful is when all
>> possible completions have a common prefix [...]
> It is useful there but only in terms on relying on completion over a
> huge set of pretty much similar symbol names which is a situation that
> shouldn't be encouraged to begin with, and neither should completion
> BTW.

Huh?  Completion is a must especially when there are many and similar
completions.  Would you consider M-x/C-h {f,v,etc} without completion
being a good user interface?

> And, alltho, as Merlin the Great Wizard was fond of saying, there is
> no right or wrong, just what is and what isn't, it still holds that
> two wrongs don't make one right.

Sure.  But the thing is that people writing packages usually don't
provide an option if INITIAL-INPUT should be used or not.  Therefore,
whatever choice they make is forced upon their users (well, unless the
user knows of :filter-args advices).  For that reason it makes sense to
document a guideline on how to do things as Arash cited in


reply via email to

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