RE: [External] : Re: Improvement proposals for `completing-read'

[Drew Adams]

> > There can be_lots_  of info that's part of a full
> > candidate which we do_not_  expose in the UI, so
> > users don't necessarily see a difference in
> > *Completions*.
> 
> If the users can't make a conscious choice between two completions based
> on info available to them, such completions shouldn't both be present in
> the completion results at the same time.

Read again, please.  "in *Completions*"

And I explicitly mentioned that some such info could
be made available to users in other ways, and that
could even be done on demand.

Lots of things are possible, depending on what's
thought to be most useful for users in the particular
context.

And even the position of a candidate in the displayed
list can, in some cases, be used to disambiguate it
from other similar-looking candidates in the list.

And narrowing can filter on <whatever>, including
data that's not necessarily displayed.  So narrowing
also can distinguish similarly named candidates.

Lots and lots and lots of things are possible.

No one is saying that we should never prefix or
suffix candidates with text that disambiguates them,
or even that just makes them quick to access.

Think Avy.  It shows disambiguating text next to
the current search hits, which you can use for easy
access.  That text is shown on demand, and only for
the current hits.

That kind of thing could be done for otherwise
ambiguous completion candidates - when you cycle to
a `foo' candidate all `foo' candidates show text
that you can use for choosing.  That's just one
possibility (and not necessarily a good one) that
comes to mind in the moment.

Tools, tools; not tool.  Not everything is a nail.

> > We can nevertheless make any such info visible
> > in other ways, e.g. on demand.
> 
> Any such attributes can be accounted for the
> duplicates-removing logic.

Sorry, hand-waving phrases don't mean much to me.

> If they aren't visible in *Completions* by
> default, that doesn't seem like great UX, though.

You can't define what's a great UI in an abstract,
blanket way.  Not usefully.

You're being dismissive, and yet it's likely that
the UI innovations of most of the completion UIs
that are found to be so useful today introduced UI
features that could have been summarily dismissed
by someone not able to see past the veil of their
current hammer.