Re: completing-read depricated initial-input

[Christopher Dimech]

> Sent: Wednesday, June 22, 2022 at 3:09 PM
> From: "Po Lu" <luangruo@yahoo.com>
> To: "Arash Esbati" <arash@gnu.org>
> Cc: "Drew Adams" <drew.adams@oracle.com>, "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: completing-read depricated initial-input
>
> Arash Esbati <arash@gnu.org> writes:
>
> > I agree that there are cases where INITIAL-INPUT still has its place,
> > but as I said, I remember the reason for phasing it out was different
> > than stylistic preferences.
>
> What other reason can there be?  I can't think of any non-stylistic
> reason to discourage using that argument.
>
> If you think it is counterproductive to insert some initial value into
> the minibuffer itself, then by all means recommend against using it.
>
> But don't obsolete the means of doing so.


Because `completing-read` is a very general function, on purpose, and
has historically been getting more and more general, the presence of
INITIAL-INPUT does have purpose.  Would want to keep `completing-read`
as a general canonical function for user input.  And I do use it, especially
when `REQUIRE-MATCH` in `t`.

Obsoleting the means of using it will introduce functional difficulties rather
than solving or simplifying anything.

There is enough agreement about the generality of `completing-read` to keep
the functionality of INITIAL-INPUT.