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: Fri, 10 Jan 2014 09:58:24 -0500 Message-ID: References: <87sit4ejpq.fsf@yandex.ru> <52C8C18A.3010501@yandex.ru> <52CA4035.2020302@yandex.ru> <52CB6BDB.4020601@yandex.ru> <52CE3FE3.4080503@yandex.ru> <87vbxs73sz.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1389365953 27989 80.91.229.3 (10 Jan 2014 14:59:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jan 2014 14:59:13 +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 Fri Jan 10 15:59:20 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 1W1dYN-0001w5-FE for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Jan 2014 15:59:19 +0100 Original-Received: from localhost ([::1]:57315 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1dYN-0006cM-41 for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Jan 2014 09:59:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51516) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1dYD-0006bH-Bp for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2014 09:59:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1dY7-0000AP-7G for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2014 09:59:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59545) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1dY7-0000AJ-3e for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2014 09:59:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W1dY6-0002Kt-KO for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2014 09:59: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: Fri, 10 Jan 2014 14:59: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.13893659078925 (code B ref 16334); Fri, 10 Jan 2014 14:59:02 +0000 Original-Received: (at 16334) by debbugs.gnu.org; 10 Jan 2014 14:58:27 +0000 Original-Received: from localhost ([127.0.0.1]:45330 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1dXW-0002Jt-LK for submit@debbugs.gnu.org; Fri, 10 Jan 2014 09:58:27 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:16078) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1dXV-0002Jl-1R for 16334@debbugs.gnu.org; Fri, 10 Jan 2014 09:58:25 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFxKG9/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBgzBHQSRCgOIYZwZgV6DFQ X-IPAS-Result: Av4EABK/CFFFxKG9/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBgzBHQSRCgOIYZwZgV6DFQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="44642310" 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; 10 Jan 2014 09:58:24 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 2C8056045A; Fri, 10 Jan 2014 09:58:24 -0500 (EST) In-Reply-To: <87vbxs73sz.fsf@yandex.ru> (Dmitry Gutov's message of "Fri, 10 Jan 2014 10:23:56 +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:83233 Archived-At: > A list of segments would a natural choice, but I was thinking about a > more radical change: allowing backends to handle the completion styles. I guess the backend could provide a property which would cause completion--nth-completion to just pass the request to the completion-table. That would be an easy change in minibuffer.el. But I'd first like to see how that would work out on the backend side: it might turn out to be pretty difficult to make it work well, or at least it might require exposing more of minibuffer.el's code (i.e. turn some "--" into "-", which implies thinking hard about whether that's really an API with which we want to live for a long time). Unless it is used to override the completion-styles: the omnisharp completion could simply ignore completion-styles and use its own omnisharp-server-provided behavior. > Firstly, one might prefer to see candidates for several styles, ranked > and merged, like described here: > https://github.com/company-mode/company-mode/issues/45#issuecomment-31564029 That sounds like a request that applies to all backends, i.e. is only part of the UI. > The main problem with this approach would be to make sure frontends can > handle not knowing which style was used to find a given completion > candidate. Currently the only UI which uses completion-styles indeed has no idea which style was used and that hasn't been a problem. In general, I can't see why that info would be necessary. Stefan