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#16334: 24.3.50; company-capf eats the first char in IELM filename completions Date: Mon, 06 Jan 2014 10:23:16 -0500 Message-ID: References: <87sit4ejpq.fsf@yandex.ru> <52C8C18A.3010501@yandex.ru> <52CA4035.2020302@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1389021864 17479 80.91.229.3 (6 Jan 2014 15:24:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Jan 2014 15:24:24 +0000 (UTC) Cc: 16334@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Jan 06 16:24:30 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 1W0C2P-0007Hl-6f for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Jan 2014 16:24:21 +0100 Original-Received: from localhost ([::1]:35808 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0C2O-0005aI-Ko for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Jan 2014 10:24:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41346) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0C2E-0005XU-MK for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2014 10:24:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0C27-0005wE-Ch for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2014 10:24:10 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:52898) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0C27-0005wA-8H for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2014 10:24:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W0C26-000123-GB for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2014 10:24: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, 06 Jan 2014 15:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 16334 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 16334-submit@debbugs.gnu.org id=B16334.13890218023908 (code B ref 16334); Mon, 06 Jan 2014 15:24:02 +0000 Original-Received: (at 16334) by debbugs.gnu.org; 6 Jan 2014 15:23:22 +0000 Original-Received: from localhost ([127.0.0.1]:38682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W0C1Q-00010v-Tv for submit@debbugs.gnu.org; Mon, 06 Jan 2014 10:23:21 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:13184) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W0C1N-00010m-Hd for 16334@debbugs.gnu.org; Mon, 06 Jan 2014 10:23:18 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFFxKG9/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kiB4GwS2NGoNwA4hhnBmBXoMVgUk X-IPAS-Result: Av8EABK/CFFFxKG9/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kiB4GwS2NGoNwA4hhnBmBXoMVgUk X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="44222106" Original-Received: from 69-196-161-189.dsl.teksavvy.com (HELO pastel.home) ([69.196.161.189]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 06 Jan 2014 10:23:16 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id B38B762F43; Mon, 6 Jan 2014 10:23:16 -0500 (EST) In-Reply-To: <52CA4035.2020302@yandex.ru> (Dmitry Gutov's message of "Mon, 06 Jan 2014 09:33:41 +0400") 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:83061 Archived-At: >>> `completion-file-name-table' is more of an exception, I think. But if >>> it was only passed the segment of STRING after the last path >>> separator, it could still look behind it in the buffer and see the >>> full path. >> But the completion may actually want to *change* the text before >> the boundary. E.g. completion of /u/s/d to /usr/share/doc. > In that case, "/usr/share/doc" is the completion candidate, not "doc", > right? Not sure what you mean by "completion candidate": try-completion and all-completions will both return nil because there's no "/u/s" directory. Assuming we use partial-completion style, completion-try-completion should return "/usr/share/doc" and completion-all-completions should return ("usr/share/doc"), i.e. without the leading "/". If we had started from "/usr/s/d" the results would have been the same except completion-all-completions would return ("share/doc"). > To be clear, I'm not convinced that the notion of "sub-fields" is > useful. Defining limits to the text that can be affected by completion only > looks good to me from the presentation point of view: if the candidate > strings can be shorter, we can show more of them in the *Candidates* buffer, > whereas it's less useful for popup-style UIs where the candidates are > displayed vertically anyway. Then just have company-capf check completion-boundaries and concat the missing prefix to every element returned by all-completions. > IOW, if I were to add a `boundaries' action to company-backends API, it > would only be used for presentation: the popup will cut off that many > characters from the candidate strings, and it will be rendered that many > columns to the right. If you want to let Company provide completion styles like partial-completion you'll need some additional info about "subfields". But as long as you limit yourself to prefix or substring completion you don't need that. > Come to think of it, though, this new action may be incompatible with the > notion of merged backends. If we have candidates that come from backends > that return the same prefix but different boundaries, there's no way to > reflect the boundaries in the popup. Yup. Just like you have a problem when the start/end of the completion text is not identical. E.g. you could have a "word" backend and a "varname" backend, and you type "my_fanc" and now the "word" backend wants to complete "fanc" whereas the varname backend wants to complete "my_fanc". Stefan