Re: Improvement proposals for `completing-read'

[Stefan Monnier <monnier@iro.umontreal.ca>]

> I would also like if `completing-read` is consistent with
> `read-from-minibuffer` in this case, since this lead to actual
> confusion, where the false assumption has been made that
> `completing-read` also accepts `t`.

No objection from me (the discussion was more because I was curious ab
out the motivation for the change).

> Maybe we will see the orderless package in ELPA at some point.

It's already in ELPA (more specifically in the MELPA archive).
But I hope it will appear in GNU ELPA, indeed.

>> As long as we can offer some way (that's not too cumbersome) to select
>> between the different cases using things like self-insert-command + RET,
>> I'm fine with it.  IOW I think it require reifying the "subtle
>> differences" as some kind of optional extra text.
> Okay, maybe I can come up with something.  This will require
> experimentation. The duplicates could be deduplicated at the UI level by
> appending some index for example "candidate (1)", "candidate (2)", ...

I think we should arrange for the completion table to provide that extra
text, so it can be more meaningful than an arbitrary number.  Also the
user needs to be able to know "which is which", so it needs to be
connected to something that's displayed in *Completions* that
distinguishes them.

E.g. maybe we could arrange for the minibuffer text to be
matched against the *annotated* candidates in some cases.  I think this
requires more thought, together with concrete examples.

> One thing to consider - maybe returning the highlights as some extra data is
> not actually faster than simply propertizing the strings?

The extra opaque data is cheap/free to compute.  It would not contain
"the highlights", but just the side information that might be needed to
compute the highlights: e.g. you can't do the highlighting correctly for
`partial-completion` without having access to the "pattern" against
which it was matches.

> I would therefore go with the simple solution first since this
> provable solves the issue.

Yes, the "skip-highlights" approach is a good solution for now.  The one
I discuss above requires a whole new API, so it's just hotair right now.


        Stefan