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: Tue, 28 Jan 2014 18:00:28 +0200 Message-ID: <52E7D41C.7050008@yandex.ru> References: <87d2jfxtzo.fsf@yandex.ru> <52E591BC.4090009@yandex.ru> <52E7422E.5050806@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 1390924882 13973 80.91.229.3 (28 Jan 2014 16:01:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Jan 2014 16:01:22 +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 Tue Jan 28 17:01:28 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 1W8B6H-0005rj-Pz for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Jan 2014 17:01:22 +0100 Original-Received: from localhost ([::1]:37997 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8B6H-00067C-G8 for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Jan 2014 11:01:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52765) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8B66-00066V-1K for bug-gnu-emacs@gnu.org; Tue, 28 Jan 2014 11:01:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W8B5y-0001lU-MV for bug-gnu-emacs@gnu.org; Tue, 28 Jan 2014 11:01:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53656) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8B5y-0001lQ-IB for bug-gnu-emacs@gnu.org; Tue, 28 Jan 2014 11:01:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W8B5y-0003l0-4I for bug-gnu-emacs@gnu.org; Tue, 28 Jan 2014 11:01:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Jan 2014 16:01: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.139092483814396 (code B ref 16555); Tue, 28 Jan 2014 16:01:02 +0000 Original-Received: (at 16555) by debbugs.gnu.org; 28 Jan 2014 16:00:38 +0000 Original-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 Original-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 Original-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) Original-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) 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:84170 Archived-At: 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.