[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [External] : Re: Stepping Back: A Wealth Of Completion systems Re: [

From: Eric Abrahamsen
Subject: Re: [External] : Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico
Date: Mon, 12 Apr 2021 12:01:04 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Drew Adams <drew.adams@oracle.com> writes:

>> > 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.
> 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, but I can
imagine it coming in handy in a larger system where the string travels
through many moving parts. Thanks.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]