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#16334: 24.3.50; company-capf eats the first char in IELM filename completions Date: Tue, 07 Jan 2014 06:52:11 +0400 Message-ID: <52CB6BDB.4020601@yandex.ru> 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; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1389063192 5984 80.91.229.3 (7 Jan 2014 02:53:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Jan 2014 02:53:12 +0000 (UTC) Cc: 16334@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jan 07 03:53:18 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 1W0Mn7-0001MO-Sz for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Jan 2014 03:53:18 +0100 Original-Received: from localhost ([::1]:38529 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0Mn7-0004iS-H2 for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Jan 2014 21:53:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46148) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0Mmy-0004i7-O4 for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2014 21:53:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0Mms-00046y-Rx for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2014 21:53:08 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54018) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0Mms-00046t-NR for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2014 21:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W0Mms-00088h-4w for bug-gnu-emacs@gnu.org; Mon, 06 Jan 2014 21:53: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, 07 Jan 2014 02:53: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.138906314031208 (code B ref 16334); Tue, 07 Jan 2014 02:53:02 +0000 Original-Received: (at 16334) by debbugs.gnu.org; 7 Jan 2014 02:52:20 +0000 Original-Received: from localhost ([127.0.0.1]:39803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W0MmB-00087H-Uq for submit@debbugs.gnu.org; Mon, 06 Jan 2014 21:52:20 -0500 Original-Received: from mail-lb0-f181.google.com ([209.85.217.181]:36575) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W0Mm9-000876-9E for 16334@debbugs.gnu.org; Mon, 06 Jan 2014 21:52:17 -0500 Original-Received: by mail-lb0-f181.google.com with SMTP id q8so10338454lbi.40 for <16334@debbugs.gnu.org>; Mon, 06 Jan 2014 18:52:15 -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=iC7eZ1RUw1uLi89LhBwWUdDG3cOr8gVVDZVOVdE6Jxw=; b=OUUII3rWqjCOtB8LwtUAYea6bMe4K11+bycX3shOP3FghYytPCFn3prn6arUkOc1xp vKlgtnklhq62wvtbdRxqfvT3g112HjJq+pbDDRd9reOf3tkRrChKsvwrGwroCdbElpLG Mw0oSZCod9JtM92uZCaw7/xAIQVcELLz2ujwNE16fEmwDAV2Mqeb8gEIFf8hFVCS888V wbNpP9ducKxbhLN7OKorZ0QJTyrPqGoIvLtWcQdiHuztxf0VK/u46rl9XD/s4KQ4nyAk y5tGI+/qU3CxyeH5Y3ZekN5Su+q+n3TWGX+0eKiaBA4hrpkVnA+xUlT0YuxvmkwAEG74 2WWA== X-Received: by 10.112.135.165 with SMTP id pt5mr2330233lbb.33.1389063135547; Mon, 06 Jan 2014 18:52:15 -0800 (PST) Original-Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id dw1sm43994556lbc.4.2014.01.06.18.52.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jan 2014 18:52:13 -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:83083 Archived-At: On 06.01.2014 19:23, Stefan Monnier wrote: >>>> `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. Maybe I didn't ask the right question. If the completion may want to change the text outside of its defined boundaries, doesn't that subvert the meaning of the "boundaries"? Or do you mean that, depending on the completion style, `completion-file-name-table' may return different boundaries, with the same prefix and suffix? So that modifications will still remain within the boundaries? >> In that case, "/usr/share/doc" is the completion candidate, not "doc", >> right? > > Not sure what you mean by "completion candidate": Elements returned by the completion table? Strings of text, one of which is likely to replace the text between completion boundaries. > 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"). Sounds quite convoluted. >> 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. Already done: https://github.com/company-mode/company-mode/compare/b70540b5fcd062c4670dea7004453de326ff4f70...8ecec3594931ae8e2329fec4b793ad4ba392e4ef >> 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. I wonder if this information has to be reflected in the backend API. For example, some external service might want to pick the completion styles itself, and we can just give the backend prefix, get back a list of completion candidates, and eventually replace the prefix with one of the candidates. Same with suffix whenever we get around to supporting that. From where I stand, knowing the completion style in advance only gives us benefits in visualization (know which characters in candidate strings match) and, in some cases, performance (no need to do concatenation even if the strings we receive from some subsystem have some offset in the prefix). On the other hand, the backend is free to try all completion styles it knows/is allowed to use, sort and return together, like in this feature request: https://github.com/company-mode/company-mode/issues/45#issuecomment-31564029, saving several network road-trips and possibly further amount of CPU time. And as far as highlighting the matching characters in candidates goes, we could just skip that for non-prefix matches (checking each on the fly), or do it sloppily, without regard for the backend logic. >> 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". We currently deal with that by only using the backends that respond with the same prefix as the first one that returned non-nil. Guess we could add the boundaries to the comparison list, too...