From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: completing-read return meta-information? Date: Wed, 16 Sep 2015 08:00:39 -0700 (PDT) Message-ID: <7c37cd21-a9e0-48fa-b5a2-a32595c43dda@default> References: <86y4g6zcuo.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1442415703 16399 80.91.229.3 (16 Sep 2015 15:01:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 16 Sep 2015 15:01:43 +0000 (UTC) To: Stephen Leake , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 16 17:01:30 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZcED9-0003fi-5y for ged-emacs-devel@m.gmane.org; Wed, 16 Sep 2015 17:01:27 +0200 Original-Received: from localhost ([::1]:51309 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcED8-0008BI-N5 for ged-emacs-devel@m.gmane.org; Wed, 16 Sep 2015 11:01:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55635) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcECV-000842-B7 for emacs-devel@gnu.org; Wed, 16 Sep 2015 11:00:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZcECP-0003PE-MY for emacs-devel@gnu.org; Wed, 16 Sep 2015 11:00:47 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:42219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZcECP-0003P7-GV for emacs-devel@gnu.org; Wed, 16 Sep 2015 11:00:41 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t8GF0eHQ014220 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Sep 2015 15:00:40 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t8GF0e1K018880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 16 Sep 2015 15:00:40 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t8GF0eve018104; Wed, 16 Sep 2015 15:00:40 GMT In-Reply-To: <86y4g6zcuo.fsf@stephe-leake.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:190020 Archived-At: > I tried storing the directory info in a text property of the > completion string; that was not returned. FWIW, I proposed years ago that a completion candidate (string) be able to be returned propertized. "Be able" means that this can be controlled, e.g., by a variable. Here is a thread about this from 2008, for instance: http://lists.gnu.org/archive/html/emacs-devel/2008-06/msg01503.html There were other threads too. FWIW, in Icicles I've done this for nearly a decade. I use this feature to recuperate information associated with an individual candidate. A candidate can be as rich as you like and return as much info as you like. The changes to the Emacs code needed to allow this are simple. > A similar situation occurs when completing in an alist; the completion > function uses assoc to read the alist, but after completing-read > returns, the caller must call assoc again. See above - same thing. Just put the full alist element on the string as a property. You can use the exact alist element: `eq'-testable. No loss of information. > `completion-metadata' doesn't seem designed for arbitrary user > information. And I'd rather not have to call the completion table > function again; that would typically require re-computing the > meta-information, or caching it somewhere. >=20 > Is there a way to return meta-information? > What would have to be changed in completing-read to make this possible? Simply return the propertized candidate as is. Makes completion far more useful.