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: propose adding Icicles to Emacs Date: Sat, 16 Jun 2007 15:36:11 -0700 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1182033404 12141 80.91.229.12 (16 Jun 2007 22:36:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 16 Jun 2007 22:36:44 +0000 (UTC) Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 17 00:36:42 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Hzgsp-00054l-9M for ged-emacs-devel@m.gmane.org; Sun, 17 Jun 2007 00:36:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hzgso-00081W-MC for ged-emacs-devel@m.gmane.org; Sat, 16 Jun 2007 18:36:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Hzgsk-0007yZ-1A for emacs-devel@gnu.org; Sat, 16 Jun 2007 18:36:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Hzgsj-0007xn-GW for emacs-devel@gnu.org; Sat, 16 Jun 2007 18:36:33 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Hzgsj-0007xg-2e for emacs-devel@gnu.org; Sat, 16 Jun 2007 18:36:33 -0400 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Hzgsh-0006Sb-7M; Sat, 16 Jun 2007 18:36:31 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5GMaTwe006438; Sat, 16 Jun 2007 17:36:29 -0500 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id l5GMG6r9001604; Sat, 16 Jun 2007 16:36:28 -0600 Original-Received: from dhcp-amer-csvpn-gw1-141-144-64-42.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 2934604621182033384; Sat, 16 Jun 2007 15:36:24 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Whitelist: TRUE X-Whitelist: TRUE X-Brightmail-Tracker: AAAAAQAAAAI= X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:73125 Archived-At: > 2. My `mouse-choose-completion' also records the number of the current > completion candidate in a global variable. This is so that > Icicles functions that work with the candidate number will also work > when you choose a candidate with the mouse, not just by cycling. > The candidate number is very important for Icicles, some functionality > being dependent on it. > > I don't understand what a "candidate number" is, and I think we will > have to consider this issue along with the core Icicles features. Let me explain. It's pretty important for Icicles. The TABLE arg to `completing-read' can be an alist whose elements can be conses whose cars are strings. The element cdrs can be anything. You can choose a candidate in different ways in Icicles, including by cycling to it and using RET, C-RET, or C-M-RET on the "current candidate" during cycling. You can also choose it with `mouse-2', `C-mouse-2', or `C-M-mouse-2' in *Completions*. In some important cases, it is not enough to recuperate the string used in *Completions* as the return value from `completing-read'. In those cases, Icicles must recuperate the entire raw candidate value from the TABLE argument - that is, it needs not only the candidate name but also its associated alist data, that is, both the car and the cdr of the candidate element. One way that Icicles does this (the best way, when it is possible) is to use the number (i.e. index) of the candidate in the TABLE arg. This index corresponds to the order of candidates when cycling and the order of the candidates in *Completions*. Keep in mind that for some commands there can be different raw candidates that have the same string name. For example, a candidate to `icicle-search' looks like this: (SEARCH-HIT-STRING . HIT-END-MARKER) or ((SEARCH-HIT-STRING BUFFER-NAME) . HIT-END-MARKER), where . SEARCH-HIT-STRING is the candidate "name", that is, the displayed candidate in *Completions*. It is a search-pattern hit. . HIT-END-MARKER is a marker at the end of the search hit. It enables search to go to the hit. . BUFFER-NAME is a string naming the buffer of the hit. It is propertized for *Completions*, to help distinguish hits from different buffers when searching across buffers. That is, when multiple buffers or files are used, the candidate displayed in *Completions* has two parts: the search-hit string and the buffer name. Users can turn this display off with a user option, so that no BUFFER-NAME is present. You can see that unless you cycle to define a "current completion candidate" to choose, or you choose it with the mouse in *Completions*, just picking it by completing its name does not necessarily uniquely identify the raw completion candidate. If there is only one matching string, then it does, but otherwise it does not. So, you see that it is important for `mouse-choose-completion' to track the candidate number, just as cycling tracks it. The need is to identify the proper raw candidate, to be able to recuperate all of its data. Yes, to forestall a question you might have, this could be implemented differently if done inside Emacs itself. Working from without, it is a bit of a workaround. Although `completing-read' lets you pass an alist as TABLE arg, it does not give you any way to recuperate the alist element given the chosen string, unless that string is unique. (You can use `assoc', but that gives you just the first element that has that string.) `completing-read' returns only the string that names the candidate, not the entire candidate element from the alist. Here, to give you an idea, is the code that recuperates a complete raw candidate value, given its string part: (defun icicle-get-alist-candidate (cand) "Return completion candidate (full entry) from `icicle-candidates-alist'. CAND is the name of the candidate (a string). If user cycled among candidates or used `mouse-2', then use the current candidate number, and ignore CAND. Otherwise: If only one candidate matches CAND, use that. Else raise an error telling user to use cycling or `mouse-2'." (and icicle-candidates-alist (let ((cand-entries (icicle-filter-alist icicle-candidates-alist icicle-completion-candidates))) (if (wholenump icicle-candidate-nb) ; Cycled or used `mouse-2'. (elt cand-entries (mod icicle-candidate-nb (length icicle-candidates-alist))) ;; If `icicle-completion-candidates' is nil, because user ;; didn't use `TAB' or `S-TAB', then `icicle-candidates-alist' ;; can contain non-matches. So, we check for more than one ;; match. However, we can't just use `assoc', because ;; candidates might be multi-completions (lists). (let ((first-match (icicle-first-matching-candidate cand icicle-candidates-alist))) (if (and first-match (not (icicle-first-matching-candidate cand (setq cand-entries (delete first-match cand-entries))))) first-match ; Only one match, so use it. (error "Ambiguous choice. Cycle or use `mouse-2' to choose \ unique matching candidate."))))))) To simplify, think of `icicle-candidate-alist' as the TABLE arg to `completing-read'. `icicle-filter-alist' filters this alist, keeping only those candidates that are current (i.e., whose strings are currently displayed in *Completions*). `icicle-first-matching-candidate' is like `assoc', but it also treats multi-completions. Again, a multi-completion is an element of the TABLE arg passed to `completing-read' whose car is a list of strings instead of a string; the strings are joined together by my `completing-read' and treated as a single candidate. Icicles uses cycling and often makes use of multiple candidates that have the same display appearance (same string), so the position of the string you choose in the list of candidates is important. Another way of saying this is that Icicles has a notion of "current candidate", which vanilla Emacs does not.