[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: completing-read depricated initial-input
From: |
Arash Esbati |
Subject: |
Re: completing-read depricated initial-input |
Date: |
Tue, 21 Jun 2022 23:28:17 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 |
Drew Adams <drew.adams@oracle.com> writes:
>> > 3. The "argument" for deprecating it amounted to only
>> > a statement that stylistically some preferred that
>> > only the DEF (default value) argument be used.
> ^^^^
>>
>> I thought the argument was "INITIAL-INPUT in too
>> intrusive in the minibuffer, most notably, when
>> it's not what the user wants, and then the hassle
>> with C-a C-k and such begins".
>
> That's an argument about UI interaction style. And
> the "only" is the real key to what's misguided.
I agree that there are cases where INITIAL-INPUT still has its place,
but as I said, I remember the reason for phasing it out was different
than stylistic preferences.
> `completing-read' is extremely general, allowing for many different
> interactions for many different kinds of use cases.
True, unfortunately.
> BTW, independently of this discussion (and even
> independently of completion), there should be a
> single key to empty the minibuffer. (Icicles
> has provided `M-k' for that forever.)
I presume you've suggested this addition to Emacs?
>> As a personal note, the INITIAL-INPUT was something in AUCTeX which
>> bugged for me for a long time, especially in queries for length
>> arguments. I can't say how often I've deleted "1.0\linewidth" in my
>> life.
>
> That you don't want INITIAL-INPUT is one thing.
> That some library might not make a good decision
> about its use is another thing.
>
> Whether INITIAL-INPUT should be deprecated is
> a third thing - something completely different.
Not sure about this one. I mean, Emacs has a lot of external (i.e., not
maintained in core) libraries and it would be a major advantage if they
all feel the same when you use them. Hence, I understand the general
direction of "deprecating a feature" to streamline the look&feel, but
you're still free to use the old feature if you think it has a added
value from a user perspective. In my example above, it wasn't a good
decision, so I changed it.
Best, Arash
- RE: [External] : Re: completing-read depricated initial-input, (continued)
Re: completing-read depricated initial-input, Robert Pluim, 2022/06/21
Re: completing-read depricated initial-input, Christopher Dimech, 2022/06/21
- RE: [External] : Re: completing-read depricated initial-input, Drew Adams, 2022/06/21
- Re: completing-read depricated initial-input, Arash Esbati, 2022/06/21
- Re: completing-read depricated initial-input, Emanuel Berg, 2022/06/21
- RE: [External] : Re: completing-read depricated initial-input, Drew Adams, 2022/06/21
- Re: completing-read depricated initial-input,
Arash Esbati <=
- RE: [External] : Re: completing-read depricated initial-input, Drew Adams, 2022/06/21
- Re: [External] : Re: completing-read depricated initial-input, Emanuel Berg, 2022/06/21
- RE: [External] : Re: completing-read depricated initial-input, Drew Adams, 2022/06/22
- standard libraries again (was: Re: [External] : Re: completing-read depricated initial-input), Emanuel Berg, 2022/06/22
- RE: standard libraries again (was: Re: [External] : Re: completing-read depricated initial-input), Drew Adams, 2022/06/22
- Re: standard libraries again (was: Re: [External] : Re: completing-read depricated initial-input), Emanuel Berg, 2022/06/22
- RE: standard libraries again (was: Re: [External] : Re: completing-read depricated initial-input), Drew Adams, 2022/06/22
- Re: standard libraries again (was: Re: [External] : Re: completing-read depricated initial-input), Emanuel Berg, 2022/06/22
Re: completing-read depricated initial-input, Arash Esbati, 2022/06/23
Re: completing-read depricated initial-input, carlmarcos, 2022/06/23