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: Tue, 28 Jan 2014 17:04:39 -0500 Message-ID: References: <87d2jfxtzo.fsf@yandex.ru> <52E591BC.4090009@yandex.ru> <52E7422E.5050806@yandex.ru> <52E7D41C.7050008@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1390946778 32511 80.91.229.3 (28 Jan 2014 22:06:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 28 Jan 2014 22:06:18 +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 Tue Jan 28 23:06:24 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 1W8GnW-0000Qx-RJ for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Jan 2014 23:06:23 +0100 Original-Received: from localhost ([::1]:39688 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8GnW-0006aY-6Q for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Jan 2014 17:06:22 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51135) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8GnK-0006Zz-MV for bug-gnu-emacs@gnu.org; Tue, 28 Jan 2014 17:06:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W8GnC-00083f-Ig for bug-gnu-emacs@gnu.org; Tue, 28 Jan 2014 17:06:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:53831) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W8GnC-00083b-G3 for bug-gnu-emacs@gnu.org; Tue, 28 Jan 2014 17:06:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W8GnB-0006mh-Sv for bug-gnu-emacs@gnu.org; Tue, 28 Jan 2014 17:06: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: Tue, 28 Jan 2014 22:06: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.139094670826001 (code B ref 16555); Tue, 28 Jan 2014 22:06:01 +0000 Original-Received: (at 16555) by debbugs.gnu.org; 28 Jan 2014 22:05:08 +0000 Original-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 Original-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 Original-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) Original-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) Original-Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id 69657B4108; Tue, 28 Jan 2014 17:04:39 -0500 (EST) 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) 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-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:84194 Archived-At: >> 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