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

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

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


From: Christopher Dimech
Subject: Re: RE: [External] : completing-read depricated initial-input
Date: Wed, 22 Jun 2022 04:59:44 +0200


> Sent: Wednesday, June 22, 2022 at 8:41 AM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Arash Esbati" <arash@gnu.org>
> Cc: "Christopher Dimech" <dimech@gmx.com>, "eliz@gnu.org" <eliz@gnu.org>, 
> "monnier@iro.umontreal.ca" <monnier@iro.umontreal.ca>, "Help Gnu Emacs" 
> <help-gnu-emacs@gnu.org>, "carlmarcos@tutanota.com" 
> <carlmarcos@tutanota.com>, "michael_heerdegen@web.de" 
> <michael_heerdegen@web.de>
> Subject: RE: [External] : Re: completing-read depricated initial-input
>
> > > 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.

The evaluation makes INITIAL-INPUT worthwhile to keep.

> 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
> INITIAL-INPUT offers.
> ___
>
> 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
> preferences.
>
> 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]