From unknown Mon Aug 18 14:26:40 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#16555 <16555@debbugs.gnu.org> To: bug#16555 <16555@debbugs.gnu.org> Subject: Status: 24.3.50; Company and CAPF: dealing with completion values containing extra text Reply-To: bug#16555 <16555@debbugs.gnu.org> Date: Mon, 18 Aug 2025 21:26:40 +0000 retitle 16555 24.3.50; Company and CAPF: dealing with completion values con= taining extra text reassign 16555 emacs submitter 16555 Dmitry Gutov severity 16555 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 25 23:12:00 2014 Received: (at submit) by debbugs.gnu.org; 26 Jan 2014 04:12:00 +0000 Received: from localhost ([127.0.0.1]:36050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W7H4h-0007Wk-4a for submit@debbugs.gnu.org; Sat, 25 Jan 2014 23:11:59 -0500 Received: from eggs.gnu.org ([208.118.235.92]:47360) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W7H4f-0007Wc-D3 for submit@debbugs.gnu.org; Sat, 25 Jan 2014 23:11:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W7H4W-0008Qr-SZ for submit@debbugs.gnu.org; Sat, 25 Jan 2014 23:11:57 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:33072) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7H4W-0008Qm-O6 for submit@debbugs.gnu.org; Sat, 25 Jan 2014 23:11:48 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49058) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7H4O-0003NU-4v for bug-gnu-emacs@gnu.org; Sat, 25 Jan 2014 23:11:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W7H4F-0008O5-Mv for bug-gnu-emacs@gnu.org; Sat, 25 Jan 2014 23:11:40 -0500 Received: from mail-ee0-x22d.google.com ([2a00:1450:4013:c00::22d]:41485) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7H4F-0008O0-FY for bug-gnu-emacs@gnu.org; Sat, 25 Jan 2014 23:11:31 -0500 Received: by mail-ee0-f45.google.com with SMTP id b15so1629384eek.4 for ; Sat, 25 Jan 2014 20:11:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:date:message-id:mime-version:content-type; bh=y5eCD6Z/nID8/ajyz6LSjtRAZIfKTN371ATOK/rlTcc=; b=jMEeziSrRXkIh/PgRbdAKvh9MKvYF5ncK+5xjVzKtIFNREia/q92Mm5xb0KnPUgdcB +dkg6aA7hNsJBiCRY4UFgepDYlksm2JSZq+dinuNbcYD4r8SOyOC4QnbZ1iAg1MSck2o +ltBqPcaGF4ivBM0ZQFADJo/S5V4BTBWK4kC/Oco2JSq7kT1iXlOLroSuOoEArPblgip /7mpxT81IqiqnNg4whsobsNIPDfueyHq6Uv2uIhJPgPJjjateWaRCP+6r+mg1O1bPrL5 OXLOYgvSCvic32n2OZF0leO5Yie2yLwv96/XF3x1JOlZJLRBCWOnVqGTV+jcUFQVH6fP 2q8w== X-Received: by 10.14.202.195 with SMTP id d43mr525176eeo.94.1390709490738; Sat, 25 Jan 2014 20:11:30 -0800 (PST) Received: from axl (213-173-121.netrunf.cytanet.com.cy. [213.7.173.121]) by mx.google.com with ESMTPSA id 4sm23913871eed.14.2014.01.25.20.11.29 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 25 Jan 2014 20:11:30 -0800 (PST) From: Dmitry Gutov To: bug-gnu-emacs@gnu.org Subject: 24.3.50; Company and CAPF: dealing with completion values containing extra text Date: Sun, 26 Jan 2014 06:11:23 +0200 Message-ID: <87d2jfxtzo.fsf@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) When dealing with code completion for programming languages, it's usual that candidates have associated text - most often, as function names, they include the argument list. Related issues: * When inserting the "common part", we must ignore the extra text. * The argument list is useful, for example when the candidate is inserted in the buffer. After it was explicitly selected, we also insert the arguments list, but replace each argument with self-erasing field when you type over it. We do that in company-clang and company-eclim (and could also do in company-senamtic, were someone to request that). * C-like languages usually provide method overloading, and then the argument list is a part of a method's identity. Any metadata is associated with the tuple "method name" + arguments, so we want to pass the method name with arguments to functions that retrieve documentation, location, etc. * If the completion table values only contained method names, `delete-duplicates' would remove all but one of the methods with the same name. But we do want to remove duplicates. At the moment the following approach emerged (for examples, again, see company-clang and company-eclim): the completion values include the argument lists (but nothing extra except that), and the respective backends define an undocumented command: `crop'. That command is only used in two situations: 1. When `company-complete-common' is called, we insert the common part among all candidates, but before that we call (backend-function 'crop "common-part"), to make sure not to insert the paren or anything after it. 2. When `company-auto-complete' feature is used, typing any character from `company-auto-complete-chars' insert the currently selected completion into the buffer. In that case we also only want to insert the method name, and so backend's `crop' function is called. When the candidate is inserted normally (by selecting it with M-p or M-n and then pressing RET), `crop' is not called. The full candidate value is inserted into the buffer, and then we call `post-completion' backend command, to allow it to remove the arguments list, or do something more advanced (see the * #2 above). This behavior is inconsistent, and `crop' doesn't sounds too good as a command name. At the risk of breaking some existing code, and thanks to `crop' stil' beging undocumented, I'd like to define a `value' command instead that would return the "cleaned" candidate text, presumably without the arguments list. It would get called anytime before the candidate text gets inserted, and to get the above mentioned templatification behavior, the `post-completion' code will need to explicitly insert the rest of the candidate text (the full candidate will be passed as the first and the only argument). Which will be the main difference from the backend's writer perspective. I see two problems: * 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? * `company-update-candidates' currently calls `company--safe-candidate' on the "common part", on the assumption that the `crop' command will return something meaningful for a string that's not itself a completion candidate (and currently, they all do, because they look for `(' instead of, say, using text properties or a hash table lookup). If the command is called `value', it would be more tempting for the implementor to only expect it to be called on actual candidates. And then it'll return nil or do something unexpected when called on something like "foo(". Thoughts? From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 26 01:23:21 2014 Received: (at 16555) by debbugs.gnu.org; 26 Jan 2014 06:23:21 +0000 Received: from localhost ([127.0.0.1]:36072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W7J7p-0002T1-2Y for submit@debbugs.gnu.org; Sun, 26 Jan 2014 01:23:21 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:10104) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W7J7n-0002Sr-4u for 16555@debbugs.gnu.org; Sun, 26 Jan 2014 01:23:19 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFMCpcb/2dsb2JhbABEuzWDWRdzgh8BBVYjEAsOJhIUGA0kiCTBLZEKA4hhnBmBXoMV X-IPAS-Result: Av8EABK/CFFMCpcb/2dsb2JhbABEuzWDWRdzgh8BBVYjEAsOJhIUGA0kiCTBLZEKA4hhnBmBXoMV X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="46092892" Received: from 76-10-151-27.dsl.teksavvy.com (HELO pastel.home) ([76.10.151.27]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 26 Jan 2014 01:23:17 -0500 Received: by pastel.home (Postfix, from userid 20848) id A256F60292; Sun, 26 Jan 2014 01:23:15 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#16555: 24.3.50; Company and CAPF: dealing with completion values containing extra text Message-ID: References: <87d2jfxtzo.fsf@yandex.ru> Date: Sun, 26 Jan 2014 01:23:15 -0500 In-Reply-To: <87d2jfxtzo.fsf@yandex.ru> (Dmitry Gutov's message of "Sun, 26 Jan 2014 06:11:23 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 16555 Cc: 16555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > * 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*. - `exit-function' would be used to insert the arglist after selecting a candidate. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 26 17:52:52 2014 Received: (at 16555) by debbugs.gnu.org; 26 Jan 2014 22:52:52 +0000 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 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 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) 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) Message-ID: <52E591BC.4090009@yandex.ru> Date: Mon, 27 Jan 2014 00:52:44 +0200 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stefan Monnier Subject: Re: bug#16555: 24.3.50; Company and CAPF: dealing with completion values containing extra text References: <87d2jfxtzo.fsf@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16555 Cc: 16555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) 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'. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 26 21:46:38 2014 Received: (at 16555) by debbugs.gnu.org; 27 Jan 2014 02:46:38 +0000 Received: from localhost ([127.0.0.1]:37093 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W7cDd-0006Ib-Gp for submit@debbugs.gnu.org; Sun, 26 Jan 2014 21:46:37 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:20166) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W7cDb-0006IS-Ck for 16555@debbugs.gnu.org; Sun, 26 Jan 2014 21:46:35 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFsoXJr/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOHwcSFBgNJIgeBsEtjVWDNQOIYZwZgV6DFQ X-IPAS-Result: Av8EABK/CFFsoXJr/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOHwcSFBgNJIgeBsEtjVWDNQOIYZwZgV6DFQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="46131937" Received: from 108-161-114-107.dsl.teksavvy.com (HELO pastel.home) ([108.161.114.107]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 26 Jan 2014 21:46:34 -0500 Received: by pastel.home (Postfix, from userid 20848) id 5CFCB60286; Sun, 26 Jan 2014 21:46:34 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#16555: 24.3.50; Company and CAPF: dealing with completion values containing extra text Message-ID: References: <87d2jfxtzo.fsf@yandex.ru> <52E591BC.4090009@yandex.ru> Date: Sun, 26 Jan 2014 21:46:34 -0500 In-Reply-To: <52E591BC.4090009@yandex.ru> (Dmitry Gutov's message of "Mon, 27 Jan 2014 00:52:44 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 16555 Cc: 16555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > * Without the additional text property, a1 and a2 are considered equal, and > only one of them is listed in the completions buffer. Hmm?? AFAIK even with the text property, they are considered equal, so it's odd that it would influence whether only one or both are displayed. AFAIK in *Completions* "duplicates" are only eliminated if their "text+annotation" is identical. > 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. Agreed. 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. While I don't want to minimize the performance problem, you also have to take into account the fact that the whole completion operation will actually do something with those strings, so 19K candidates will typically suffer from performance problems elsewhere. > 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. Conceptually, it does seem cleaner to me, indeed. >> - `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). It does correspond exactly. > `finished' can only be the status when the inserted completion doesn't > have any possible continuations in the completions table, That description was from the point of view of "TAB-style completion". In the case of company-complete-selection', we know that even if there could be further continuations, the user's action indicates he doesn't want those, so it really should be `finished'. IOW the problem is one of how to better document the meaning of `finished'. > 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'. Then I guess that company-complete-common wouldn't want to pass `finished' to the exit-function. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 28 00:38:01 2014 Received: (at 16555) by debbugs.gnu.org; 28 Jan 2014 05:38:01 +0000 Received: from localhost ([127.0.0.1]:38626 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W81N1-0002UN-Qt for submit@debbugs.gnu.org; Tue, 28 Jan 2014 00:38:01 -0500 Received: from mail-ea0-f180.google.com ([209.85.215.180]:37236) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W81Mx-0002U9-UR for 16555@debbugs.gnu.org; Tue, 28 Jan 2014 00:37:56 -0500 Received: by mail-ea0-f180.google.com with SMTP id o10so2144084eaj.11 for <16555@debbugs.gnu.org>; Mon, 27 Jan 2014 21:37:54 -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=KJz1naAPiW42Xrx4hVVYA2lX9WxLh53Pf1HePj31IJo=; b=L+Cf41UdUcsLHlS9014kDvUGviA5l4fzBS94gUQxnbdTAyfH4ltfFS4z57emEM4pBm zY2/CSjCKfKFL0s8E4PWwWgWNa1Z95qzosIcOtn2fKovjciKIhWohxWIVeOQ8jWRGnWK b6jsI0KX+Z1VNX0KTMF3L2//6Kf41BKFalswFfiIcoBS2yWlGlSeIlDkAOA9kwAPxtH3 Avgd/AoCsQTnXB+6be7/czOf6nDWigc4UGqTr+MpOCwiE/29b6GgmDJBvaY0oJWcZPJ7 zw0cHEirN1zrr+vmoGCCRVZASEXZ/Fq0gP+nfZC24OmfgMO9jVu5wMQOYNUgI6fBKLz3 e77Q== X-Received: by 10.14.0.201 with SMTP id 49mr608373eeb.38.1390887474790; Mon, 27 Jan 2014 21:37:54 -0800 (PST) Received: from [192.168.10.2] (83-4-210.netrunf.cytanet.com.cy. [83.168.4.210]) by mx.google.com with ESMTPSA id w4sm51077999eef.20.2014.01.27.21.37.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Jan 2014 21:37:54 -0800 (PST) Message-ID: <52E7422E.5050806@yandex.ru> Date: Tue, 28 Jan 2014 07:37:50 +0200 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stefan Monnier Subject: Re: bug#16555: 24.3.50; Company and CAPF: dealing with completion values containing extra text References: <87d2jfxtzo.fsf@yandex.ru> <52E591BC.4090009@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16555 Cc: 16555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 27.01.2014 04:46, Stefan Monnier wrote: >> * Without the additional text property, a1 and a2 are considered equal, and >> only one of them is listed in the completions buffer. > > Hmm?? AFAIK even with the text property, they are considered equal, so > it's odd that it would influence whether only one or both are displayed. > AFAIK in *Completions* "duplicates" are only eliminated if their > "text+annotation" is identical. Indeed, sorry, I made a wrong conclusion (when it tried it, the annotation function didn't work because it used the `eq' test). But should we document that the only way to retain the information about different annotations corresponding to equal strings is to use text properties? I don't see any other way. Like mentioned, hash tables don't work: (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 tt (make-hash-table :test 'eq) a1 "aaa" a2 "aaa" a3 "aab") (puthash a1 "a1" tt) (puthash a2 "a2" tt) (puthash a3 "a3" tt) (defun annota (s) (format "(%s)" (gethash s tt "?"))) aa| -> aaa(?), aab(?) `company-capf' would be affected, too, since it uses `completion-all-completions' now, and the latter, via `completion-basic-all-completions', passes the completions through `completion-hilit-commonality', which intentionally creates new strings. And if text properties is the only way, maybe disperse with the annotation function and just document the desired property on the strings? > 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. > > While I don't want to minimize the performance problem, you also have to > take into account the fact that the whole completion operation will > actually do something with those strings, so 19K candidates will > typically suffer from performance problems elsewhere. Well, I'm not sure: at least in this case, as you can see, fetching the candidates is an order or magnitude faster than separating their annotations. `all-completions' and `try-completion' are also faster than annotation processing, as well as `sort', but not, surprisingly, `delete-dups' (which can be replaced with `delete-consecutive-dups', however, which is also fast), and when displaying, we only need to work with a few elements of the whole completions list, so that takes more or less constant time. But that's an extreme case: Emacs symbols, where we have the list readily at hand. As an opposite example, I have a completion backend which fetches candidates from an external Ruby process (also not the fastest of languages). Walking through all classes and returning all methods defined anywhere takes about 3.2s, the resulting list is 16K long in this case, and processing annotations takes 120ms. So in this case we're good. >> `finished' can only be the status when the inserted completion doesn't >> have any possible continuations in the completions table, > > That description was from the point of view of "TAB-style completion". > In the case of company-complete-selection', we know that even if there > could be further continuations, the user's action indicates he doesn't > want those, so it really should be `finished'. > > IOW the problem is one of how to better document the meaning of `finished'. But wouldn't it clash with the current completion-at-point interface? I don't think we can define a CAPF function without regard to how it work there. >> 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'. > > Then I guess that company-complete-common wouldn't want to pass > `finished' to the exit-function. It won't call the exit-function at all, currently, so when going though company-capf, exit-function would only be called with `finished'. That's another discrepancy, I guess. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 28 08:24:33 2014 Received: (at 16555) by debbugs.gnu.org; 28 Jan 2014 13:24:33 +0000 Received: from localhost ([127.0.0.1]:38753 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W88eV-0006t4-2J for submit@debbugs.gnu.org; Tue, 28 Jan 2014 08:24:33 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:24345) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W88eS-0006sv-Q6 for 16555@debbugs.gnu.org; Tue, 28 Jan 2014 08:24:29 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFHO+IO1/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kiB4GsR+QDpEKA4hhiXmSIIFegxU X-IPAS-Result: Av8EABK/CFHO+IO1/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kiB4GsR+QDpEKA4hhiXmSIIFegxU X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="46246239" Received: from 206-248-131-181.dsl.teksavvy.com (HELO pastel.home) ([206.248.131.181]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 28 Jan 2014 08:24:28 -0500 Received: by pastel.home (Postfix, from userid 20848) id BA1D7604AC; Tue, 28 Jan 2014 08:24:27 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#16555: 24.3.50; Company and CAPF: dealing with completion values containing extra text Message-ID: References: <87d2jfxtzo.fsf@yandex.ru> <52E591BC.4090009@yandex.ru> <52E7422E.5050806@yandex.ru> Date: Tue, 28 Jan 2014 08:24:27 -0500 In-Reply-To: <52E7422E.5050806@yandex.ru> (Dmitry Gutov's message of "Tue, 28 Jan 2014 07:37:50 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 16555 Cc: 16555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > But should we document that the only way to retain the information about > different annotations corresponding to equal strings is to use text > properties? We could add a note somewhere, I guess. So far, "different completions for equal strings" is a very rare situation. > And if text properties is the only way, maybe dispense with the annotation > function and just document the desired property on the strings? None of the annotation functions so far use text-properties, because the completion candidate strings are all different anyway. I'd rather not force them to construct the annotation ahead of time "just in case it might get displayed". ELISP> (js2-time (mapcar >>> (lambda (s) >>> (if (> (length s) 2) >>> (propertize s 's (substring s (/ (length s) 2))) >>> s)) >>> (all-completions "" obarray 'fboundp))) The comparison is not really fair. Try comparing (mapcar (lambda (s) (if (> (length s) 2) (substring s 0 (/ (length s) 2)) s)) (all-completions "" obarray 'fboundp))) to (mapcar (lambda (s) (if (> (length s) 2) (let ((bound (/ (length s) 2)) (comp (substring s 0 bound))) (propertize comp 'annotation (substring s bound))) s)) (all-completions "" obarray 'fboundp))) which can be optimized to (mapcar (lambda (s) (if (> (length s) 2) (let ((bound (/ (length s) 2)) (comp (substring s 0 bound))) (put-text-property 0 bound 'annotation s comp) comp) s)) (all-completions "" obarray 'fboundp))) Where the (substring s bound) is delayed to the annotation-function. > Well, I'm not sure: at least in this case, as you can see, fetching the > candidates is an order or magnitude faster than separating their > annotations. That's also because you artificially moved a lot of processing to the all-completions step whereas some of that processing really belongs to the annotation step. >> That description was from the point of view of "TAB-style completion". >> In the case of company-complete-selection', we know that even if there >> could be further continuations, the user's action indicates he doesn't >> want those, so it really should be `finished'. >> IOW the problem is one of how to better document the meaning of `finished'. > But wouldn't it clash with the current completion-at-point interface? I don't see why. The `finished' case is exactly for things like "insert a terminator, record the user's choice somewhere, or some other thing which only makes sense when you somehow know this part of the completion is over". > I don't think we can define a CAPF function without regard to how it > work there. Can't see why not. >>> 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'. >> Then I guess that company-complete-common wouldn't want to pass >> `finished' to the exit-function. > It won't call the exit-function at all, currently, so when going though > company-capf, exit-function would only be called with `finished'. > That's another discrepancy, I guess. completion-at-point doesn't always call exit-function either. Maybe Company could be improved to call the exit-function from company-complete-common in the same way as completion-at-point, but that's just a "quality of implementation" issue, it shouldn't affect the API, AFAICT. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 28 11:00:38 2014 Received: (at 16555) by debbugs.gnu.org; 28 Jan 2014 16:00:38 +0000 Received: from localhost ([127.0.0.1]:39439 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W8B5Y-0003k6-KA for submit@debbugs.gnu.org; Tue, 28 Jan 2014 11:00:37 -0500 Received: from mail-ee0-f44.google.com ([74.125.83.44]:50008) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W8B5V-0003jx-7z for 16555@debbugs.gnu.org; Tue, 28 Jan 2014 11:00:34 -0500 Received: by mail-ee0-f44.google.com with SMTP id c13so323115eek.17 for <16555@debbugs.gnu.org>; Tue, 28 Jan 2014 08:00:31 -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=quIadVp5mrwykUg1Ddi7zvDIDq23eehgqEYFcVCQxoQ=; b=ozx4c19E27wVU/2mTZMn5QHp23B2g6IURwi3ojlzHzGwJGUsuuzP7ehkyjWSaBKIA6 msweMlRylsIMN5BJqDwRWuBzZ0Ss82jGbjfvA+H6PKyfQwExn5Zchk+r2Ruo9TjEl940 jGboUz2TwLfW4+ihqo778ahvWJhPG4qNDjDGSehngQUpvgjACnqo4tZTevto+PL+DacP u3imsQf+iy6M2R1W+kAD37e9Iek30EPIMgKH89TDyfCBg3F04Jq54T/tyIKGMXYXKwK9 6KEpp8M2MmEs4PVCUqT5zkirHBNhfxZpmePnhmo8SXTCe4nAqmEKQyJwFvWviBgb9OhW Nt9w== X-Received: by 10.14.224.70 with SMTP id w46mr585658eep.89.1390924831918; Tue, 28 Jan 2014 08:00:31 -0800 (PST) Received: from [192.168.0.94] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id v7sm57126520eel.2.2014.01.28.08.00.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Jan 2014 08:00:31 -0800 (PST) Message-ID: <52E7D41C.7050008@yandex.ru> Date: Tue, 28 Jan 2014 18:00:28 +0200 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stefan Monnier Subject: Re: bug#16555: 24.3.50; Company and CAPF: dealing with completion values containing extra text References: <87d2jfxtzo.fsf@yandex.ru> <52E591BC.4090009@yandex.ru> <52E7422E.5050806@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16555 Cc: 16555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 28.01.2014 15:24, Stefan Monnier wrote: >> But should we document that the only way to retain the information about >> different annotations corresponding to equal strings is to use text >> properties? > > We could add a note somewhere, I guess. So far, "different completions > for equal strings" is a very rare situation. Not "different completions", but rather different displayed information and exit behavior. AFAICS, using annotation-function is a very rare situation by itself (in Emacs core, only `lisp-completion-at-point' does). I blame the bare-bones completion interface. Note that we're discussing both CAPF and company-backends interfaces here. And "different completions for equal strings" would be true for company-eclim, company-clang, probably company-semantic eventually, and also third-party packages: emacs-eclim (it bundles a different Company backend), and omnisharp-emacs. We could consider it a bug, though (that annotation-function is called with different objects). Currently, the fact that `-all-completions' functions for different styles process the returned list with `completion-hilit-commonality' in undocumented. Maybe we should push that logic somewhere, or just document that -all-completions functions must process annotations themselves first? Though sorting, in `minibuffer-completion-help', would become more complicated and slower as a result. Come to think of it, company-backends should be able to use a hash-table with `eq' test maybe already, or if I massage the code a little. The major question for me was about uniqueness, and looks like, yes, doing `delete-consecutive-dups' after fetching all annotations should be fast enough (and this approach even has some space for optimization). So that leaves a problem with CAPF. >> And if text properties is the only way, maybe dispense with the annotation >> function and just document the desired property on the strings? > > None of the annotation functions so far use text-properties, because the > completion candidate strings are all different anyway. It could be an either/or specification: if annotation-function is defined, use it, otherwise, look up the `annotation' property. And actually, `completion-all-completions' already conveys some information to the front-end using text properties: it uses `face' to delimit the "common" parts of the completions using `completion-hilit-commonality'. > I'd rather not > force them to construct the annotation ahead of time "just in case it > might get displayed". But completion-at-point calls annotation-function on all completions anyway: in `minibuffer-completion-help'. After sorting, but before deleting duplicates. Or otherwise, how would it only delete duplicates only where both value and annotation are the same? > (mapcar (lambda (s) > (if (> (length s) 2) > (let ((bound (/ (length s) 2)) > (comp (substring s 0 bound))) > (put-text-property 0 bound 'annotation s comp) > comp) > s)) > (all-completions "" obarray 'fboundp))) Using `put-text-property' is a good point. > Where the (substring s bound) is delayed to the annotation-function. > ... > That's also because you artificially moved a lot of processing to the > all-completions step whereas some of that processing really belongs to > the annotation step. But that step gets performed for all candidates anyway (see above). Using `value-function' instead of `annotation-function' would have changed that. Although yes, that interface would be less neat. >> But wouldn't it clash with the current completion-at-point interface? > > I don't see why. The `finished' case is exactly for things like "insert > a terminator, record the user's choice somewhere, or some other thing > which only makes sense when you somehow know this part of the completion > is over". > >> I don't think we can define a CAPF function without regard to how it >> work there. > > Can't see why not. Yeah, okay. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 28 17:05:08 2014 Received: (at 16555) by debbugs.gnu.org; 28 Jan 2014 22:05:08 +0000 Received: from localhost ([127.0.0.1]:39617 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W8GmJ-0006lJ-TD for submit@debbugs.gnu.org; Tue, 28 Jan 2014 17:05:08 -0500 Received: from mercure.iro.umontreal.ca ([132.204.24.67]:34735) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W8GmH-0006l7-JZ for 16555@debbugs.gnu.org; Tue, 28 Jan 2014 17:05:06 -0500 Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id 2934C84A09; Tue, 28 Jan 2014 17:05:04 -0500 (EST) Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 919991E5B7C; Tue, 28 Jan 2014 17:04:39 -0500 (EST) Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 69657B4108; Tue, 28 Jan 2014 17:04:39 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#16555: 24.3.50; Company and CAPF: dealing with completion values containing extra text Message-ID: References: <87d2jfxtzo.fsf@yandex.ru> <52E591BC.4090009@yandex.ru> <52E7422E.5050806@yandex.ru> <52E7D41C.7050008@yandex.ru> Date: Tue, 28 Jan 2014 17:04:39 -0500 In-Reply-To: <52E7D41C.7050008@yandex.ru> (Dmitry Gutov's message of "Tue, 28 Jan 2014 18:00:28 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.81, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_POURMOI 0.01, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -2.8 (--) X-Debbugs-Envelope-To: 16555 Cc: 16555@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) >> We could add a note somewhere, I guess. So far, "different completions >> for equal strings" is a very rare situation. > Not "different completions", but rather different displayed information and > exit behavior. Yes, that's what I meant by "different completions with equal strings". > AFAICS, using annotation-function is a very rare situation by itself (in > Emacs core, only `lisp-completion-at-point' does). I blame the bare-bones > completion interface. No need to blame anyone/anything. CAPF needs to improve the annotation support, indeed. I don't think the current annotation-function is sufficient, since there are different kinds of annotations. E.g. adding "" is not the same as adding "(int x, float y, Vector)" for simple reasons of screen real estate, so in some UIs you'd want to display both, while in others you'd only want the short one. > We could consider it a bug, though (that annotation-function is called with > different objects). Not really: the "objects" you're talking about are returned by the completion-table, i.e. they cover at most one "field" (in the completion-boundaries sense), whereas completion-all-completions returns strings that can span several fields, so clearly they can't always be `eq' to something returned by the completion-table. > Currently, the fact that `-all-completions' functions for different > styles process the returned list with completion-hilit-commonality' in > undocumented. Indeed, but it's only part of the reason for the problem you see. And there's no way to do the highlighting elsewhere: only the style knows how to relate the input string (and point's position within in) to the various output candidates. > Maybe we should push that logic somewhere, or just document > that -all-completions functions must process annotations > themselves first? The idea is rather to let the backend provide more kinds of annotations and let the UI choose which one to use. E.g. icomplete-mode doesn't want any annotation at all, because its screen real-estate is very limited. So completion-all-completions can't blindly add annotations. > Though sorting, in minibuffer-completion-help', would become more > complicated and slower as a result. I don't see how that's related. > Come to think of it, company-backends should be able to use a hash-table > with `eq' test maybe already, or if I massage the code a little. The major > question for me was about uniqueness, and looks like, yes, doing > delete-consecutive-dups' after fetching all annotations should be fast > enough (and this approach even has some space for optimization). So that > leaves a problem with CAPF. That sounded like "thinking out loud for myself". I don't know what you wanted to say nor how that relates to CAPF. FWIW, minibuffer-completion-help uses `sort' on the "annotated completions" and then display-completion-list uses delete-consecutive-dups (tho hand written into the loop). >>> And if text properties is the only way, maybe dispense with the annotation >>> function and just document the desired property on the strings? >> None of the annotation functions so far use text-properties, because the >> completion candidate strings are all different anyway. > It could be an either/or specification: if annotation-function is defined, > use it, otherwise, look up the `annotation' property. I think that in most cases the annotation function will want to do some work rather than just return the content of the annotation (as in the sample code in my previous message). > But completion-at-point calls annotation-function on all completions anyway: minibuffer-completion-help does. completion-at-point also does when it delegates to minibuffer-completion-help. But minibuffer-force-complete doesn't. And neither does icomplete. > After sorting, but before deleting duplicates. Indeed. > But that step gets performed for all candidates anyway (see above). As shown above, no, not always. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 28 17:51:25 2014 Received: (at 16555-done) by debbugs.gnu.org; 28 Jan 2014 22:51:25 +0000 Received: from localhost ([127.0.0.1]:39643 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W8HV6-0007v1-Gn for submit@debbugs.gnu.org; Tue, 28 Jan 2014 17:51:24 -0500 Received: from mail-ea0-f174.google.com ([209.85.215.174]:57023) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W8HV4-0007uq-2C for 16555-done@debbugs.gnu.org; Tue, 28 Jan 2014 17:51:22 -0500 Received: by mail-ea0-f174.google.com with SMTP id b10so531466eae.5 for <16555-done@debbugs.gnu.org>; Tue, 28 Jan 2014 14:51:21 -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=oh/DVx8h2crVXNUx3L2Dv9WvcfBYDzR6GLnrk3BCNWE=; b=LUCNVGaWA/QjwImE1VEYlKNRjBQNzOxzlKjft/u1/EDYXA7mJXFzwlake863+c+fVB jApFeQc1rcz1X3nYFdVf0ksl5IX53HM7ak+kQTDV3w82FAmEKU+v824LE7asK9Czh4zn bLsAtXAq4C0mYT/xABcuu+IGtJ1fYGaB6Ye1oli0boXiIlPqWS51Z2aEwjlBwpHKYgW/ SomQyt0GgR6Wvcnqih30jYqIRBaWETKMitUws3kI7O0YL9HDvrlKY74uhIQv/Q+XMxhH esEAaNBpe9y4kgvTKGCfjUqV/Wd+GB+WHz/0Dmqs+pks2PBbbuOmJ5v7pHuC8xLT2rP9 endQ== X-Received: by 10.14.87.195 with SMTP id y43mr4516921eee.32.1390949481100; Tue, 28 Jan 2014 14:51:21 -0800 (PST) Received: from [192.168.10.2] (62-151-136.netrun.cytanet.com.cy. [62.228.151.136]) by mx.google.com with ESMTPSA id n7sm675987eef.5.2014.01.28.14.51.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Jan 2014 14:51:20 -0800 (PST) Message-ID: <52E83465.6030604@yandex.ru> Date: Wed, 29 Jan 2014 00:51:17 +0200 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stefan Monnier Subject: Re: bug#16555: 24.3.50; Company and CAPF: dealing with completion values containing extra text References: <87d2jfxtzo.fsf@yandex.ru> <52E591BC.4090009@yandex.ru> <52E7422E.5050806@yandex.ru> <52E7D41C.7050008@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16555-done Cc: 16555-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 29.01.2014 00:04, Stefan Monnier wrote: > CAPF needs to improve the annotation > support, indeed. I don't think the current annotation-function is > sufficient, since there are different kinds of annotations. E.g. adding > "" is not the same as adding "(int x, float y, Vector)" for > simple reasons of screen real estate, so in some UIs you'd want to > display both, while in others you'd only want the short one. I'm not sure differentiating between them would be beneficial. We already have "full document" annotation (company-doc-buffer), "one-line" annotation (company-docsig), and just "annotation" itself. If we're going to differentiate between different kinds of short annotations, this will make 4 different functions a backend would need to define to describe a candidate with words. FWIW, "(int x, float y, Vector)" looks short enough to me. In Ruby, it often looks like "(table_name, column_name, [options])", which isn't too long and still allows completion-at-point display candidates in two columns. >> We could consider it a bug, though (that annotation-function is called with >> different objects). > > Not really: the "objects" you're talking about are returned by the > completion-table, i.e. they cover at most one "field" (in the > completion-boundaries sense), whereas completion-all-completions returns > strings that can span several fields, so clearly they can't always be > `eq' to something returned by the completion-table. I see. Then I'm out of ideas here, and using text properties, as non-obvious that is, indeed remains the best option. > The idea is rather to let the backend provide more kinds of annotations > and let the UI choose which one to use. E.g. icomplete-mode doesn't > want any annotation at all, because its screen real-estate is > very limited. So completion-all-completions can't blindly add annotations. Thanks for pointing that out. >> Come to think of it, company-backends should be able to use a hash-table >> with `eq' test maybe already, or if I massage the code a little. The major >> question for me was about uniqueness, and looks like, yes, doing >> delete-consecutive-dups' after fetching all annotations should be fast >> enough (and this approach even has some space for optimization). So that >> leaves a problem with CAPF. > > That sounded like "thinking out loud for myself". I don't know what you > wanted to say nor how that relates to CAPF. It was. Sorry if it's out of place. I filed this bug for discussing a new feature in both Company and CAPF, and that was me summing up the (one-sided) discussion of it on the Company side. So, closing. > FWIW, > minibuffer-completion-help uses `sort' on the "annotated completions" > and then display-completion-list uses delete-consecutive-dups (tho hand > written into the loop). Yes, delete-consecutive-dups in Company is also inlined (in `company-calculate-candidates'), we couldn't use the function itself anyway, cause it's 24.4-only. >> It could be an either/or specification: if annotation-function is defined, >> use it, otherwise, look up the `annotation' property. > > I think that in most cases the annotation function will want to do some > work rather than just return the content of the annotation (as in the > sample code in my previous message). Hm, yes, indeed. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 28 20:34:40 2014 Received: (at 16555-done) by debbugs.gnu.org; 29 Jan 2014 01:34:40 +0000 Received: from localhost ([127.0.0.1]:39698 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W8K36-0003Ts-2A for submit@debbugs.gnu.org; Tue, 28 Jan 2014 20:34:40 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:60475) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W8K33-0003Tf-Qm for 16555-done@debbugs.gnu.org; Tue, 28 Jan 2014 20:34:38 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFFpZg5/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kiB4GsR+QDpEKA4hhnBmBXoMV X-IPAS-Result: Av8EABK/CFFFpZg5/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kiB4GsR+QDpEKA4hhnBmBXoMV X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="46306803" Received: from 69-165-152-57.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([69.165.152.57]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 28 Jan 2014 20:34:34 -0500 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 1A8A8AE267; Tue, 28 Jan 2014 20:34:34 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#16555: 24.3.50; Company and CAPF: dealing with completion values containing extra text Message-ID: References: <87d2jfxtzo.fsf@yandex.ru> <52E591BC.4090009@yandex.ru> <52E7422E.5050806@yandex.ru> <52E7D41C.7050008@yandex.ru> <52E83465.6030604@yandex.ru> Date: Tue, 28 Jan 2014 20:34:34 -0500 In-Reply-To: <52E83465.6030604@yandex.ru> (Dmitry Gutov's message of "Wed, 29 Jan 2014 00:51:17 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 16555-done Cc: 16555-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >> CAPF needs to improve the annotation support, indeed. I don't think >> the current annotation-function is sufficient, since there are >> different kinds of annotations. E.g. adding "" is not the same as >> adding "(int x, float y, Vector)" for simple reasons of >> screen real estate, so in some UIs you'd want to display both, while >> in others you'd only want the short one. > I'm not sure differentiating between them would be beneficial. We already > have "full document" annotation (company-doc-buffer), "one-line" annotation > (company-docsig), and just "annotation" itself. If we're going to > differentiate between different kinds of short annotations, this will make > 4 different functions a backend would need to define to describe a candidate > with words. > FWIW, "(int x, float y, Vector)" looks short enough to me. In Ruby, > it often looks like "(table_name, column_name, [options])", which isn't too > long and still allows completion-at-point display candidates in two columns. Hmm... I guess you're right. > I see. Then I'm out of ideas here, and using text properties, as > non-obvious that is, indeed remains the best option. Agreed. >> That sounded like "thinking out loud for myself". I don't know what you >> wanted to say nor how that relates to CAPF. > It was. Sorry if it's out of place. No, no, feel free to think out loud. I just wasn't sure if I'd missed something or what. > I filed this bug for discussing a new feature in both Company and > CAPF, and that was me summing up the (one-sided) discussion of it on > the Company side. So, closing. So, IIUC the conclusion is "if the string's chars is not enough, you have to store the extra info in text-properties". Not sure where we could put this info, but if you can think of a place, feel free to add it. Stefan From unknown Mon Aug 18 14:26:40 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 26 Feb 2014 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator