help-gnu-emacs
[Top][All Lists]
Advanced

[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



reply via email to

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