From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#16555: 24.3.50; Company and CAPF: dealing with completion values containing extra text Date: Sun, 26 Jan 2014 21:46:34 -0500 Message-ID: References: <87d2jfxtzo.fsf@yandex.ru> <52E591BC.4090009@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1390790834 11923 80.91.229.3 (27 Jan 2014 02:47:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jan 2014 02:47:14 +0000 (UTC) Cc: 16555@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 27 03:47:21 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 1W7cEK-0002mZ-G7 for geb-bug-gnu-emacs@m.gmane.org; Mon, 27 Jan 2014 03:47:20 +0100 Original-Received: from localhost ([::1]:57127 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7cEK-0002JV-5U for geb-bug-gnu-emacs@m.gmane.org; Sun, 26 Jan 2014 21:47:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49707) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7cEA-0002JP-Gd for bug-gnu-emacs@gnu.org; Sun, 26 Jan 2014 21:47:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W7cE3-0001Kf-4q for bug-gnu-emacs@gnu.org; Sun, 26 Jan 2014 21:47:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51307) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W7cE3-0001Kb-0u for bug-gnu-emacs@gnu.org; Sun, 26 Jan 2014 21:47:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W7cE2-0006JH-HO for bug-gnu-emacs@gnu.org; Sun, 26 Jan 2014 21:47:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Jan 2014 02:47:02 +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.139079079824221 (code B ref 16555); Mon, 27 Jan 2014 02:47:02 +0000 Original-Received: (at 16555) by debbugs.gnu.org; 27 Jan 2014 02:46:38 +0000 Original-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 Original-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" Original-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 Original-Received: by pastel.home (Postfix, from userid 20848) id 5CFCB60286; Sun, 26 Jan 2014 21:46:34 -0500 (EST) 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) 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:84085 Archived-At: > * 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