[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: completing-read depricated initial-input
From: |
carlmarcos |
Subject: |
Re: completing-read depricated initial-input |
Date: |
Thu, 23 Jun 2022 13:48:35 +0200 (CEST) |
Jun 23, 2022, 11:26 by tsdh@gnu.org:
> Emanuel Berg <incal@dataswamp.org> 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
> <86mte3lsj2.fsf_-_@gnu.org>.
>
So now emacs is getting into the habit of trashing code by looking at written
packages by figuring out what is not usually done by the majority? It is a bad
strategy, to say the least. Even worse, it looks as if the documentation in
putting
in people's head that INITIAL-INPUT should not be used in any function where
it is defined as an argument.
> Bye,
> Tassilo
>
- Re: completing-read depricated initial-input, (continued)
- Re: completing-read depricated initial-input, Christopher Dimech, 2022/06/23
- Re: completing-read depricated initial-input, Emanuel Berg, 2022/06/23
- Re: completing-read depricated initial-input, Po Lu, 2022/06/21
- Re: completing-read depricated initial-input, Emanuel Berg, 2022/06/21
- Re: completing-read depricated initial-input, Christopher Dimech, 2022/06/22
- Re: completing-read depricated initial-input, Arash Esbati, 2022/06/23
- Re: completing-read depricated initial-input, Emanuel Berg, 2022/06/23
- Re: completing-read depricated initial-input, Tassilo Horn, 2022/06/23
- Re: completing-read depricated initial-input, Emanuel Berg, 2022/06/23
- Re: completing-read depricated initial-input, Tassilo Horn, 2022/06/23
- Re: completing-read depricated initial-input,
carlmarcos <=
- Re: completing-read depricated initial-input, Emanuel Berg, 2022/06/23
- Re: completing-read depricated initial-input, Christopher Dimech, 2022/06/24
- Re: completing-read depricated initial-input, Emanuel Berg, 2022/06/23
- Re: completing-read depricated initial-input, Arash Esbati, 2022/06/23
- Re: completing-read depricated initial-input, Lars Ingebrigtsen, 2022/06/23
- Re: completing-read depricated initial-input, Tassilo Horn, 2022/06/23
- Re: completing-read depricated initial-input, Arash Esbati, 2022/06/23
- Re: completing-read depricated initial-input, Robert Pluim, 2022/06/23
- Re: completing-read depricated initial-input, Arash Esbati, 2022/06/23
- Re: completing-read depricated initial-input, Philip Kaludercic, 2022/06/24