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

[Drew Adams]

> >> > I already mentioned that you can put the _full_ candidate
> >> > -- whatever Lisp object it might be -- on the _display_
> >> > candidate, which is just a string.
> >>
> >> I missed that the first time around! That's an interesting approach, and
> >> one that hadn't occurred to me. In the simplest case it ends up being
> >> way, way more code than just referencing the alist again,
> >
> > Why do you think so?  You have the string; you just use
> > `get-text-property' to get from it anything you need.
> >
> > (Not to mention that looking up a key in an alist (1)
> > takes time and (2) doesn't allow for duplicate keys.)
> 
> I mean that using `put-text-property' on one side of the
> `completing-read' and `get-text-property' on the other is more code
> (okay, maybe I was exaggerating, but it's still more code) than building
> an alist on one side of the `completing-read' and then using
> (cdr (assoc-string on the other. There may be other advantages to the
> approach, but what I'd like to see is `completing-read' (or
> `selecting-read') doing this job itself.

I don't think you're right about the relative work/code in
those two cases, but I won't argue about that.

I will say (again) that (cdr (assoc-string...)) won't deal
with duplicate keys.  You or someone else spoke of unique
objects.  Alist keys are not, in general, unique, even
when alist elements might be.  That's one reason I use the
approach I described (when I use it).  

Here's the doc string of a function I use to get the full
alist candidate that corresponds to a STRING display
candidate.  You can see that having the full candidate on
the string as a text property is one case - true some of
of the time.  In other cases I don't do that.

,----
| icicle-get-alist-candidate is a compiled Lisp function in
| 'icicles-fn.el'.
| 
| (icicle-get-alist-candidate STRING &optional NO-ERROR-P)
| 
| Return full completion candidate that corresponds to displayed STRING.
| STRING is the name of the candidate, as shown in `*Completions*'.
| Non-nil optional argument NO-ERROR-P means display a message and
| return nil instead of raising an error if STRING is ambiguous.
| If the value of NO-ERROR-P is `no-error-no-msg', then show no message
| and just return nil.
| 
| If `icicle-whole-candidate-as-text-prop-p' is non-nil, then the full
| candidate might be available as text property `icicle-whole-candidate'
| of STRING.  If so, then that is used.
| 
| Otherwise, the full candidate is obtained from
| `icicle-candidates-alist'.  In this case:
|  If the user cycled among candidates or used `mouse-2', then use the
|    current candidate number, and ignore STRING.
|  Otherwise:
|    If only one candidate matches STRING, use that.
|    Else respect NO-ERROR-P and tell user to use cycling or `mouse-2'.
`----

[FWIW, I don't want completing-read to do any such thing in
all cases.  Maybe you meant on demand, e.g., with some new
arg.  I do it on demand, indicating when I want/need it by
binding `icicle-whole-candidate-as-text-prop-p'.  And yes,
it's done in the Icicle mode version of `completing-read'.]