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

[Eric Abrahamsen]

Philip Kaludercic <philipk@posteo.net> writes:

> Jean Louis <bugs@gnu.support> writes:
>
>> * Philip Kaludercic <philipk@posteo.net> [2021-04-11 18:53]:
>>> Jean Louis <bugs@gnu.support> writes:
>>> 
>>> > One way I use for complex data structures is to have some kind of ID
>>> > and visual description, then by using the ID I fetch the data
>>> > structure later.
>>> 
>>> I'm not sure I completely understood your example. What do hash tables
>>> offer over lists of objects that can have a programmed
>>> representation?
>>
>> Completing read supports hash tables, once representation candidate
>> has been selected one can then use the key to get value of some quite
>> different or very complex data structure.
>>
>> (setq h (make-hash-table :test 'equal))
>> (puthash "United States" [("ABC" 30 t)] h)
>> (puthash "Australia" 2 h)
>> (puthash "United Kingdom" 3 h)
>>
>> (message "%s" (gethash (completing-read "Choice: " h) h)) ⇒ "[(ABC 30 t)]"
>
> But don't you think that it is weird that completing-read returns the
> representation and not the object itself. That is exactly what I want to
> avoid by having the representation computed using a method.
>
> The best I can think of is using hash-maps to generate anonymous methods
> but even that seems to be looking at the issue backwards.

This is my main complaint with `completing-read' -- you can pass it data
structures like alists or hash tables, but you still only get the string
keys back out of it. In the past I've imagined being able to pass a
lambda to `completing-read' (as if it didn't have enough arguments) that
would be used to extract the desired value. If we're going to build an
ad-hoc structure specifically for completion, we could just build it
inside the call to `completing-read', and it could do the caching and
value extraction.