[Top][All Lists]

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

Re: completing-read depricated initial-input

From: Christopher Dimech
Subject: Re: completing-read depricated initial-input
Date: Wed, 22 Jun 2022 06:56:47 +0200

> Sent: Wednesday, June 22, 2022 at 3:09 PM
> From: "Po Lu" <>
> To: "Arash Esbati" <>
> Cc: "Drew Adams" <>, "Christopher Dimech" 
> <>, "" <>, "" 
> <>, "Help Gnu Emacs" <>, 
> "" <>, 
> "" <>
> Subject: Re: completing-read depricated initial-input
> Arash Esbati <> 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.

reply via email to

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