[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: |
Fri, 24 Jun 2022 21:33:16 +0200 |
> Sent: Saturday, June 25, 2022 at 2:30 AM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Emanuel Berg" <incal@dataswamp.org>, "help-gnu-emacs@gnu.org"
> <help-gnu-emacs@gnu.org>
> Subject: RE: [External] : Re: completing-read depricated initial-input
>
> > I already asked, what concept is the initial value?
> ...
> > "Why is the computer putting stuff there? It's
> > the area where the human user should put stuff."
> ...
> > There is only one use case (completion with a
> > common prefix)
>
> Please read (again?) what others have written.
>
> First, it's initial _input_, not initial value. It's
> about prefilling the minibuffer with particular text,
> which you can use any way you like (e.g. edit it).
>
> A common prefix is only one such use case. (For one
> thing, prefix completion isn't all there is nowadays.)
>
> As the arg to `completing-read', `read-from-minibuffer',
> `read-string', `read-buffer', `read-minibuffer', etc.,
> it's unrelated to any default value. (More precisely,
> it's not _necessarily_ related.)
>
> There's no reason it shouldn't be possible to provide
> you an initial-input that's useful for editing, even
> one that might not be directly related to any default
> value.
> ___
>
> As for inserting the _default value_ (not the INIT arg)
> in the minibuffer automatically: a user might want that.
> You might not; others might. This should be a user
> choice, not imposed one way or the other.
>
> As I said:
>
> If you often want to use or edit the default value,
> then consider setting `icicle-default-value' to
> non-`nil' and non-`t' [to insert it in the minibuffer].
>
> If you rarely do so, then consider using `nil' or `t'
> [to not insert it].
>
> As one user, I'm in the former camp: I often want
> to use or edit the default value, and as a result I
> prefer that it be inserted automatically.
>
> That is, I prefer to hit a key to delete it, in the
> (fewer) cases where I don't want it, than to have to
> hit `M-n' to insert it, in the (more numerous) cases
> where I do want it (including to edit it, rather
> than just accept it as is).
>
> Remember that minibuffer reading is not always, or
> even usually, a must-match situation. Even for
> completion, there's lax completion (REQUIRE-MATCH
> nil).
>
> With well-designed code a `completing-read' call
> with lax completion can nevertheless provide a
> helpful default value - e.g., one that I might want
> to edit slightly.
>
> Of course, a `completing-read' call that gives you
> a poor default value lessens the utility of using
> it, and so lessens the usefulness of inserting it.
>
> Again, this want-or-don't-want-DEF-inserted is akin
> to whether to use `delete-selection-mode'. I do
> use that mode. Users are different.
>
> And it's important, IMO, to have a single key to
> empty the minibuffer, regardless of where point is.
> In `icy-mode' that's `M-k', by default. Vanilla
> Emacs still has no such key. (Why not?)
>
> Neither (1) having to use `M-n' to insert the
> default, nor (2) having to use `M-k' to erase its
> automatic insertion, is super bothersome. Each
> can make sense and be preferred by some users.
> That's all.
> ___
>
> Summary:
>
> 1. There are uses for an initial-input arg.
> 2. Automatic insertion of the default value can
> be useful and preferred by some users. Let
> users choose.
> 3. Emacs shouldn't deprecate, let alone get rid
> of, an initial-input arg for `completing-read'.
> In fact, it should consider adding one for
> some functions that don't have it - some of
> the `read-*' functions, for example.
I fully support the summary as well.
- Re: completing-read depricated initial-input, (continued)
- Re: completing-read depricated initial-input, Jean Louis, 2022/06/24
- Re: completing-read depricated initial-input, Emanuel Berg, 2022/06/24
- Re: completing-read depricated initial-input, Jean Louis, 2022/06/24
- Re: completing-read depricated initial-input, Emanuel Berg, 2022/06/25
- Re: completing-read depricated initial-input, Jean Louis, 2022/06/25
- Re: completing-read depricated initial-input, Emanuel Berg, 2022/06/26
- RE: [External] : Re: completing-read depricated initial-input, Drew Adams, 2022/06/24
- Re: RE: [External] : completing-read depricated initial-input,
Christopher Dimech <=
- Re: [External] : Re: completing-read depricated initial-input, Emanuel Berg, 2022/06/25
- RE: [External] : Re: completing-read depricated initial-input, Drew Adams, 2022/06/25
- Re: [External] : Re: completing-read depricated initial-input, Emanuel Berg, 2022/06/26
- RE: [External] : Re: completing-read depricated initial-input, Drew Adams, 2022/06/26
- Re: [External] : Re: completing-read depricated initial-input, Emanuel Berg, 2022/06/26
- Re: completing-read depricated initial-input, Christopher Dimech, 2022/06/24
- Re: completing-read depricated initial-input, Jean Louis, 2022/06/24
- Re: completing-read depricated initial-input, Christopher Dimech, 2022/06/24
- RE: [External] : Re: completing-read depricated initial-input, Drew Adams, 2022/06/23
- Re: RE: [External] : completing-read depricated initial-input, Christopher Dimech, 2022/06/24