From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#16555: 24.3.50; Company and CAPF: dealing with completion values containing extra text Date: Mon, 27 Jan 2014 00:52:44 +0200 Message-ID: <52E591BC.4090009@yandex.ru> References: <87d2jfxtzo.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1390776797 7367 80.91.229.3 (26 Jan 2014 22:53:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 26 Jan 2014 22:53:17 +0000 (UTC) Cc: 16555@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Jan 26 23:53:23 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1W7YZs-0003Dm-Tr for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Jan 2014 23:53:21 +0100 Original-Received: from localhost ([::1]:56601 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7YZs-0000Ud-Dm for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Jan 2014 17:53:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52664) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7YZi-0000US-85 for bug-gnu-emacs@gnu.org; Sun, 26 Jan 2014 17:53:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W7YZa-00052A-SI for bug-gnu-emacs@gnu.org; Sun, 26 Jan 2014 17:53:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51213) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7YZa-000526-P9 for bug-gnu-emacs@gnu.org; Sun, 26 Jan 2014 17:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W7YZZ-0006Zs-Su for bug-gnu-emacs@gnu.org; Sun, 26 Jan 2014 17:53:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 26 Jan 2014 22:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16555 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16555-submit@debbugs.gnu.org id=B16555.139077677225268 (code B ref 16555); Sun, 26 Jan 2014 22:53:01 +0000 Original-Received: (at 16555) by debbugs.gnu.org; 26 Jan 2014 22:52:52 +0000 Original-Received: from localhost ([127.0.0.1]:36999 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W7YZP-0006ZT-CW for submit@debbugs.gnu.org; Sun, 26 Jan 2014 17:52:51 -0500 Original-Received: from mail-ee0-f45.google.com ([74.125.83.45]:55090) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W7YZN-0006ZL-FB for 16555@debbugs.gnu.org; Sun, 26 Jan 2014 17:52:50 -0500 Original-Received: by mail-ee0-f45.google.com with SMTP id b15so1914070eek.18 for <16555@debbugs.gnu.org>; Sun, 26 Jan 2014 14:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=00zvab5zd6IL8KP9PR5pBnYLOJQRPsyYhOHuAM1l5BY=; b=GuYXbLQS+CG5r1ftIlZPfs2Gc9cHZEgW5NcZIpzMAjk6Qk7RvXkhG5ze7wnT+YsUiW 9fjOpoCmHKKqwxssrCGjJ4orr0VHKmGcmd4DF1CM4LUP4wQcfowPrjEc5Nilp2Fldx6c UdMti6VogAHshnduclXTEw8amPE0fPrWvVMdRElNcQq+i+0ZsxU4B3z2Oh3sunCOovGj kpbKADkpe8ktfXYz2sYudp5mrwvtZvNF/SCQ5wZupfQHI8iO4Np38fU5qbcZLrh/Z039 R7lbhSjK4iUP5t4Ulo+37x1d1QbRtKuirkLePVN6iyJUajczud+Ti/Ld6Xc9721t3ATM bN0A== X-Received: by 10.14.32.67 with SMTP id n43mr22290713eea.17.1390776768650; Sun, 26 Jan 2014 14:52:48 -0800 (PST) Original-Received: from [192.168.10.2] (213-173-121.netrunf.cytanet.com.cy. [213.7.173.121]) by mx.google.com with ESMTPSA id k41sm34636323eey.0.2014.01.26.14.52.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Jan 2014 14:52:47 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:84071 Archived-At: On 26.01.2014 08:23, Stefan Monnier wrote: >> * Including extra text in completion table seems like it won't mesh well >> with the completion-at-point-functions interface, and specifically >> with the completion-at-point as the frontend. How would one write a >> CAPF function for clang or eclim with argument lists in mind? > > From a CAPF point of view, I think it would work as follows: > - all-completions would return the "cropped" names. > - `annotate-function' would be used to add the arglists to *Completions*. I played with this a bit, and looks like the proper way to make this work with the current completion-at-point code is to use text properties. I propertize the completions, and then the annotation function looks up the text property: (add-hook 'completion-at-point-functions (lambda () (let ((bounds (bounds-of-thing-at-point 'symbol))) (when bounds (list (car bounds) (cdr bounds) (list a1 a2 a3) :annotation-function #'annota)))) nil t) (setq a1 (propertize "aaa" 'a "a1") a2 (propertize "aaa" 'a "a2") a3 (propertize "aab" 'a "a3")) (defun annota (s) (format "(%s)" (get-text-property 0 'a s))) Using a hash table surprizingly didn't work, because: * Without the additional text property, a1 and a2 are considered equal, and only one of them is listed in the completions buffer. * If the hash table uses the `eq' test, lookup fails because the strings passed to the annotation function are not the same objects as those we return in the completions table. * If the hash table uses the `equal' test, naturally it can't distinguish between a1 and a2 (lookup returns "a2" for both). Is that how it's supposed to work? And it looks to me that this approach is incompatible with the `value' command, if we want company-capf to support it. Using the annotation function, it would know how to get from value to value + annotation, but not the other way around. Using `value' as described, aside from smoother transition from the current behavior, appealed to me because it allows to defer the string munging to the last possible moment, thus saving in performance on all strings that weren't displayed, when the candidates list is large. But here's an extreme example, of sorts: ELISP> (js2-time (all-completions "" obarray 'fboundp)) 0.0121 ELISP> (js2-time (mapcar (lambda (s) (if (> (length s) 2) (propertize s 's (substring s (/ (length s) 2))) s)) (all-completions "" obarray 'fboundp))) 0.1318 The second measurement fluctuates between 130ms and 80ms, probably due to GC. Maybe this is negligible, considering that on my machine that's a collection with 19000 elements, and most completion lists will be considerably smaller. On the other hand, using `annotate' cleanly separates the "meat" in completion candidates from the extra text, which can be used to e.g. visualize them differently, maybe with different faces and alignments in the popup. As long as we solve the issue of uniqueness. > - `exit-function' would be used to insert the arglist after selecting > a candidate. Yes, `exit-function' is the best match for `post-completion', but I don't see which value of STATUS should be considered as okay for insertion. `finished' seems to be a good candidate, but it does not seem to really correspond to when happens after `company-complete-selection' (the completion is inserted and the popup is closed). `finished' can only be the status when the inserted completion doesn't have any possible continuations in the completions table, whereas we obviously want to be able to do arglist insertion for these cases, too. The reverse is also true: being able not to insert the arguments list for a sole candidate can also be useful, and in Company user can do that at least by repeatedly using TAB (company-complete-common) instead of `company-complete-selection'.