From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel 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 Message-ID: <87o8ejqqdr.fsf@ericabrahamsen.net> References: <9c9af088-580f-9fb1-4d79-237a74ce605c@inventati.org> <874kgkxxs0.fsf@posteo.net> <87blamp5hy.fsf@posteo.net> <2ce73f33-8675-211a-9eb7-ea63de1a161e@yandex.ru> <871rbh6pd4.fsf@posteo.net> <87sg3w6co0.fsf@posteo.net> <87pmyz4xom.fsf@posteo.net> <87mtu3sc0v.fsf@ericabrahamsen.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13508"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Philip Kaludercic , "emacs-devel@gnu.org" , Dmitry Gutov To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Apr 12 21:03:02 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lW1pt-0003OT-FD for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Apr 2021 21:03:01 +0200 Original-Received: from localhost ([::1]:57952 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lW1ps-0007Sn-DX for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Apr 2021 15:03:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48048) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lW1oK-0006av-By for emacs-devel@gnu.org; Mon, 12 Apr 2021 15:01:25 -0400 Original-Received: from ericabrahamsen.net ([52.70.2.18]:43484 helo=mail.ericabrahamsen.net) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lW1o9-0007bA-Kr for emacs-devel@gnu.org; Mon, 12 Apr 2021 15:01:24 -0400 Original-Received: from localhost (c-71-197-184-122.hsd1.wa.comcast.net [71.197.184.122]) (Authenticated sender: eric@ericabrahamsen.net) by mail.ericabrahamsen.net (Postfix) with ESMTPSA id 2BC34FA20D; Mon, 12 Apr 2021 19:01:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericabrahamsen.net; s=mail; t=1618254066; bh=CFYR37u9Y2V9j8botEo9iMuSVN4cDmCuycGcQ3Lmbmc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=s/e7VeWLB6oRpYXw6/H2WYRWMxLQm9AD6lES69gihua+oHRxaCWS+aulSH0Dx+1YF 6dSD6mNoKFNBEflxdmhvorsJMKqUtouD9Y8C/xl1QWoCrT9fyECLqv+ePU5+Eo2eB3 GYsnsRrr3Cp376/7jVR1mHAQNbTfm7sBZGutI/fU= In-Reply-To: (Drew Adams's message of "Mon, 12 Apr 2021 18:36:12 +0000") Received-SPF: pass client-ip=52.70.2.18; envelope-from=eric@ericabrahamsen.net; helo=mail.ericabrahamsen.net X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:267976 Archived-At: Drew Adams 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.