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

[Christopher Dimech]

> Sent: Friday, June 24, 2022 at 4:30 AM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Michael Heerdegen" <michael_heerdegen@web.de>, "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>
> Subject: RE: [External] : Re: completing-read depricated initial-input
>
> > > (let ((list '("iffalse" "iftrue" "else" "fi")))
> > >   (completing-read "Macro: "
> > >                    (mapcar (lambda (x) (concat "\\" x)) list)
> > >                    nil nil "\\"))
> >
> > A convincing example, in my opinion.
>
> Yes, it's a typical use case for non-nil INIT
> arg: inserting a prefix.
>
> And it's also essentially the case for non-nil
> `insert-default-directory' for `read-file-name'.
>
> (Try setting `insert-default-directory' to nil,
> and see if you like it.  Now imagine if Emacs
> hard-coded the behavior as nil and decided to
> tell users that inserting `default-directory'
> is deprecated...)
>
> This case can arise if you use `try-completion'
> to obtain such a common prefix, and then you use
> `completing-read' to get the completion the user
> wants.
>
> Another example:
> (completing-read "Color: " (defined-colors)
>                  nil nil (buffer-substring-no-properties
>                            (widget-field-start widget)
>                            (point)))
> ___
>
> Another typical use case is when the HIST arg is a
> cons, so you can insert a particular history element
> and position the cursor after it.
>
> This case is what the doc string of `completing-read'
> (misguidedly) says is the _only_ use case:
>
>   (This is the only case in which you should use
>   INITIAL-INPUT instead of DEF.)
>
> (Our docs shouldn't use "should", BTW. ;-))
>
> And it's not even necessarily a case of "instead
> of DEF".  Using INIT here doesn't exclude also
> using a DEF value.

Correct, there are use cases for init and def to be different,
and for who do not want init, nil is specified.

But I do agree with the recommendation of not using initial-value,
is not based on the existence of any coherent problem to elisp
package success.  Looking at in, the discouragement is deeply
rooted around the use cases seen in many packages.  And ignore
the truly great ones that might use initial-value it future.