RE: [External] : Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico

[Drew Adams]

> > Regarding "interpreting completion as selection" and "text
> > expansion", I am unsure if there is a big difference. You always start
> > with a set of possible completions and only for very few styles a
> > prefix completion is possible. This has been mentioned before in this
> > thread, I think.
> 
> I don't start with any set, I start with an (usually)
> empty prompt and type a few letter, tab to check and
> then press enter.

You start with empty input.  But when starting the
operation (reading input with possible candidates
for completion) you are also starting with a set
of candidates that you can conveniently choose -
a domain of choices.

The set of such convenient choices is _not_ limited
to those provided to `completing-read' by way of
its COLLECTION argument.  (And that argument can be
a function, which can provide an infinite number of
candidates.)

It includes the "candidates" of the DEF list, which
you can also choose from easily, albeit in a
different way (e.g. M-p, M-r) from using TAB.

Similar considerations apply to `read-file-name',
and even other read functions, including
`read-from-minibuffer'.  Some such functions don't
even provide for "completion", and yet they let you
easily choose among a specified set of "candidates".

And those are just the candidates you can choose
_conveniently_.  Many read functions let you input
nearly any text.  Even lax completion (nil REQUIRE)
lets you do that.

You want to separate a notion of "selection" from
a notion of "completion" (the latter in the Emacs
sense).  That unnecessarily focuses not on the user
actions (input, choosing, acting on, canceling...)
but on _one kind_ of resulting action: replacing
some input string with an output string.  That's
quite limiting.

(And note that even in that case the output need
not be longer than - a real "completion" of - the
input.)

That's a narrow focus, and isn't very helpful, IMO.

Something like `completing-read' or `read-file-name'
(or even `read-from-minibuffer') has multiple moving
parts - different subsystems, providing different
functionalities.  What's important is their possible
use together - the synergy they provide.

Suppose we focus on that whole - the combination
(and probably including other functionalities not
yet included).  Do we need a new name, instead of
"completion"?  I think not, but I don't really care
(except for a maintenance burden renaming entails).

Sure, "completion" doesn't really mean all of those
things.  But it never meant all of what Emacs has
always provided for its "completion".  So what?

I like finding "le mot juste" as much as the next
person.  But at some point it just doesn't matter.
No one is getting confused by Emacs using the term
"completion" to mean such a constellation of things,
I expect.

And sometimes there _isn't_ a mot juste.  And just
inventing a new word van be more of a cop-out than
a solution to the fact that "completion" in its
usual sense doesn't cover all of what Emacs means
by that term.

> But even so, there are situations where selection
> would be preferable. Usually when I don't know
> what my options are.

Emacs "completion" is multidimensional.  That's the
point.  Don't call it "completion" if the term
bothers you.  The point is that you can make use of
it in any direction/dimension or any combination
of them.

> > I am actually quite satisfied with the status quo given the many
> > package options, where everyone seems to find a good fit. But maybe
> > the name `completing-read` does not reflect anymore what it is since
> > it is often used for something else than simple prefix expansion. The
> > prefix/basic completion is baked pretty deeply in the completion APIs,
> > e.g., `all-completions` and this got relaxed afterwards.
> 
> Well FWIW I'm not.

You already said that for you it's "not about
filtering a data set but expanding a string."

You reject a point of view that "it's about" a
bunch of things, working together, to achieve
lots of different kinds of goals.

If you limit yourself to a single, expand-a-string
purpose, then it's not surprising that you, well,
ultimately find yourself limited.  That doesn't
mean that what Emacs (already) offers is limited.

(Sounds like the classic joke about someone hitting
his head against the wall and a doctor prescribing,
as remedy, "Don't do that.")