[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: Sun, 26 Jun 2022 22:22:46 +0000

> >>> Automatic insertion of the default value
> >>> can be useful and preferred by some users.
> >>> Let users choose.
> >> Make that an option
> > I detailed just such an option.
> But then you'd need initial-input even less?

I've already explained that a default value is
something different from an initial-input value -
they have different behavior and thus different
uses - and why that remains true even if someone
chooses to automatically insert the default value.

And I posted some of the doc, which makes clear
that the option values that insert the default
value do so only when the INIT-VALUE is a no-op:

  When [the option] is non-nil and non-t,
  and the initial-input argument is nil or "", 
  the default value can be inserted into the
  minibuffer as the initial input.

E.g., if you set the option to `insert-end' then
the default value is inserted (with point after
it) *ONLY IF* there's no INIT-VALUE to insert.

This inserts the default value, `jjj':

(completing-read "q: " '(aaa bbb ccc ddd)
                 nil nil "" nil "jjj")
                          ^       ^
                        init    default

But if there's an INIT-VALUE then it's inserted.
This inserts `iii':

(completing-read "q: " '(aaa bbb ccc ddd)
                 nil nil "iii" nil "jjj")
                           ^         ^
                         init      default

[I also suggested it might be useful to give
users some general control over the INIT-VALUE.
Icicles hasn't done that - it just adds user
control of the default value.  For INIT-VALUE
Icicles just respects the vanilla behavior.
You know - the arg that Emacs itself claims is
deprecated?  Icicles respects that one, as is.]

reply via email to

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