help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: completing-read depricated initial-input


From: Arash Esbati
Subject: Re: completing-read depricated initial-input
Date: Thu, 23 Jun 2022 22:58:48 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50

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.

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



reply via email to

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