[Top][All Lists]

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

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

From: Drew Adams
Subject: RE: [External] : Re: completing-read depricated initial-input
Date: Thu, 23 Jun 2022 16:23:08 +0000

> >> > `completing-read' is extremely general,
> >> > allowing for many different interactions
> >> > for many different kinds of use cases.
> >>
> >> True, unfortunately.
> > Why "unfortunately"?
> 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?

> > And there's `read-from-minibuffer', which is
> > even more general.
> Therefore we have `read-string'.

We have both specific and general functions that
read input - both with and without completion.

`completing-read' is a general completion
workhorse function.  Among other things, you can
use it to define your own specific completion

When a specific read function is appropriate, use
it.  That's not a reason for not also having more
general functions.

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.

reply via email to

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