From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Completion Date: Sat, 1 Sep 2018 07:49:55 -0700 (PDT) Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1535813287 3092 195.159.176.226 (1 Sep 2018 14:48:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 1 Sep 2018 14:48:07 +0000 (UTC) To: Lars Ingebrigtsen , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Sep 01 16:48:03 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fw7Bx-0000eu-Bb for ged-emacs-devel@m.gmane.org; Sat, 01 Sep 2018 16:48:01 +0200 Original-Received: from localhost ([::1]:37493 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fw7E3-0006oY-I5 for ged-emacs-devel@m.gmane.org; Sat, 01 Sep 2018 10:50:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35567) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fw7Dw-0006nR-7e for emacs-devel@gnu.org; Sat, 01 Sep 2018 10:50:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fw7Ds-0007w5-4x for emacs-devel@gnu.org; Sat, 01 Sep 2018 10:50:04 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:49748) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fw7Dr-0007vx-HC for emacs-devel@gnu.org; Sat, 01 Sep 2018 10:50:00 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w81Ei8vI125319; Sat, 1 Sep 2018 14:49:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=+L3z0qexwI3P6oaEVFANoP+yA7LZNoLJpHQtebwDkT4=; b=C1myuhIMeCtUpGgsvqOwLxnZYOlYTf+T2FBo3BkWF8EWbRaY+88qVQ0prTDjyrFFtxAw LP7cXje7n5LDa2Rb1vuD00yiAGx9lcoyHMyLH1OBRmpRhJV82qT6A0ARRyMsUlSKUIIs v8PC7L4epjqml7pAIiuhrTw0vIrDzENOrYvhxy9coCQ+nSS79aTTTsni2Wg2V1fLlSf9 jOq4DZ4wgf0Nd80JsoOfvpSy0bG1PKJiXfN5qzebKrnBuWKcMPksZgc/nxOz8x/pLJCm ZGzxCGTbU6XC9fFF5Im9MB/Ucixu4+BiEswXMa135+R+gFIGs3hUDGPVyp1FQl82Zml4 vw== Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp2120.oracle.com with ESMTP id 2m7kdq1m0k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 01 Sep 2018 14:49:57 +0000 Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w81Enurl030868 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 1 Sep 2018 14:49:56 GMT Original-Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w81Enuxg014028; Sat, 1 Sep 2018 14:49:56 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4732.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9002 signatures=668708 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1809010166 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 156.151.31.85 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:229162 Archived-At: > I've been looking at the completion functions and documentation for > pretty much the first time in my life this morning, and I've got some > questions. :-/ Replying quickly to some of them - > 2) The entire `completing-read' machinery is based on prefix, matches > and nothing else; is that right? =20 No. See variable `completion-styles'. Literal prefix completion is the `bas= ic' completion style. In vanilla Emacs there is only one set of completion styles that is ever in= effect, defined by option `completion-styles'. It is a list of different = ways to match your input. Each style in the list is tried, in turn, until = one of them successfully completes your input. All completion candidates you see come from the same style. You have no co= ntrol over which style will actually be used for any given input, other tha= n ordering the list ahead of time. And you have no way of knowing which sty= le was actually used to produce a given set of candidates. The relation bet= ween your input pattern and the matches is thus sometimes not so clear. The= re is no way to know, for example, that initial matching failed and partial= matching succeeded. That is, in vanilla Emacs the styles of `completion-styles' can only be use= d together - all or none; they are never alternatives that you can choose a= t runtime. Icicles respects vanilla Emacs `completion-styles' as one of several possib= le completion "methods" (the method called `vanilla'). Unlike completion st= yles, Icicles completion methods are alternatives - only one is used at a t= ime to complete your input, and you can switch from one method to another e= asily. For method `vanilla', which uses `completion-styles', Icicles gives you way= s to change the current set of styles on the fly. Option `icicle-completion= -style-sets' is a list of possible `completion-styles' values to choose fro= m. You can flip among these during completion. Among other things, this means that you can try completing using one style = set and, if that doesn't succeed, switch to another. Any of the sets in `icicle-completion-style-sets' can contain any number of= styles, in any order. In particular, a set can be a singleton, which mean= s that you can selectively try to complete using different individual style= s. > 3) The completion selection machinery in simple.el is nice, but it would > be nice to be able to pass more information about the strings into it > and get it all back after the user has chosen something. The obvious > thing is to put a text property on the strings, and that almost, almost > works, except for this: >=20 > (defun choose-completion (&optional event) ... > (buffer-substring-no-properties beg end))))) >=20 > If that had been just `buffer-substring', then the information would > survive back to the caller. I proposed this for Emacs many years ago. It is what Icicles does. Option `= icicle-unpropertize-completion-result-flag' controls this (nil by default). Non-nil means strip text properties from the completion result. Set or bind this option to non-nil only if you need to ensure, for some other library, that the string returned by `completing-read' and `read-file-name' has no text properties. Typically, you will not use a non-nil value. Internal text properties added by Icicles are always removed anyway. A non-nil value lets you also remove properties such as `face'. And yes, with Icicles you often put the complete alist-entry (or other valu= e), as a text property, on the string that is displayed as a candidate, and= then you retrieve that full value. This can be done automatically. (defun icicle-put-whole-cand-prop (cand) "Put cdr of CAND on its car, as text property `icicle-whole-candidate'= . This has no side effects. Returns a new propertized string corresponding to (car CAND)." (let ((text-cand (copy-sequence (car cand)))) (put-text-property 0 (length text-cand)=20 'icicle-whole-candidate (cdr cand) text-cand) (setcar cand text-cand) text-cand)) It can also be useful sometimes to allow multiple full candidates that have= the same display-candidate string (apart from the full-candidate text prop= erty).=20 For example, command `icicle-search' uses completion to navigate among sear= ch hits. Duplicate search hits are retained. Although some search-hit can= didates might have the same text, they are located at different buffer posi= tions (and perhaps in different buffers). The position is available in the = full-candidate info. There are many other `completing-read' enhancements that Icicles uses, each= of which I've proposed for Emacs in the past. > `minibuffer-allow-text-properties' exists.=20 Icicles binds it to t for `completing-read' (but not for `read-from-minibuf= fer'). Icicles uses `icicle-unpropertize-completion-result-flag' instead to= control this for `completing-read'.