Re: completing-read depricated initial-input

[Christopher Dimech <dimech@gmx.com>]

> Sent: Friday, June 24, 2022 at 8:58 AM
> From: "Arash Esbati" <arash@gnu.org>
> To: "Drew Adams" <drew.adams@oracle.com>
> 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: completing-read depricated initial-input
>
> Drew Adams <drew.adams@oracle.com> writes:
>
> >> Because extremely general tools give one many
> >> ways to do things.
> >
> > And?  Emacs and Elisp are all about giving us
> > many ways to do things.  They even give you lots
> > of rope to hang yourself with.
> >
> >> It is just hard if you find out afterwards that
> >> things went in the wrong direction and you try
> >> to clean up.  No other reason.
> >
> > Too general/abstract.  Can you elaborate with
> > some specifics?
>
> I don't have any specific example in my mind, I was also thinking about
> what you said above about the rope and hang yourself.
>
> > No one's obliged to use the very general function
> > `completing-read'.  And no one's obliged to use
> > it with a non-nil INITIAL-INPUT arg.
>
> Agreed.
>
> But in terms of coming to some sort of conclusion: This thread started
> with the question:
>
>   When do you plan to remove the `INITIAL-INPUT` argument from
>   `completing-read`?
>
> I think the answer is: This will not happen, so don't worry.

The bigger problem is really about whether the functionality associated with
INITIAL-INPUT will end?

> If so, is the docstring of `completing-read' inaccurate or misleading?
> If so, should there be a bug report and/or a change suggestion?
>
> WDYT?
>
> Best, Arash
>