[Top][All Lists]

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

RE: [External] : Re: completing-read depricated initial-input

From: Drew Adams
Subject: RE: [External] : Re: completing-read depricated initial-input
Date: Tue, 21 Jun 2022 20:41:31 +0000

> > 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.

Different users can prefer different interactions.
Different coders can prefer different interactions
for different calls to `completing-read'.

There is no one-size-fits-all.  `completing-read'
is extremely general, allowing for many different
interactions for many different kinds of use cases.

Even if Godot proclaimed that ONE style of use is
"better" for most interactions, that's not, in
itself, a reason to not provide also for what

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.)  

> And if I compare:
> (let ((default "FOO"))
>   (completing-read (format "Prompt (default %s): " default)
>                    '("FOO" "BAR" "BAZ")
>                    nil nil nil nil default))
> where I hit ENTER or TAB makes more sense to me than this:
> (let ((default "FOO"))
>   (completing-read "Prompt: "
>                    '("FOO" "BAR" "BAZ")
>                    nil nil default))
> where I hit ENTER or have to delete the entry
> before I can proceed with TAB.

That may make more sense to you.  It may always
make more sense to you.  It may make more sense
to you in that example.

Those preferences might be arguments in favor
of providing ways for a user to configure such

None of them is an argument why INITIAL-INPUT
should be deprecated.

> 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.

reply via email to

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