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: Thu, 09 Jan 2014 11:00:10 -0500 Message-ID: References: <87sit4ejpq.fsf@yandex.ru> <52C8C18A.3010501@yandex.ru> <52CA4035.2020302@yandex.ru> <52CB6BDB.4020601@yandex.ru> <52CE3FE3.4080503@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1389283289 11928 80.91.229.3 (9 Jan 2014 16:01:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Jan 2014 16:01:29 +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 Thu Jan 09 17:01:35 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 1W1I2r-0001tm-H3 for geb-bug-gnu-emacs@m.gmane.org; Thu, 09 Jan 2014 17:01:21 +0100 Original-Received: from localhost ([::1]:52700 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1I2q-0005BZ-R1 for geb-bug-gnu-emacs@m.gmane.org; Thu, 09 Jan 2014 11:01:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41717) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1I2g-0005AR-12 for bug-gnu-emacs@gnu.org; Thu, 09 Jan 2014 11:01:17 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1I2Y-0002jB-Mi for bug-gnu-emacs@gnu.org; Thu, 09 Jan 2014 11:01:09 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58263) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1I2Y-0002j6-JF for bug-gnu-emacs@gnu.org; Thu, 09 Jan 2014 11:01:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W1I2Y-0000Ea-1l for bug-gnu-emacs@gnu.org; Thu, 09 Jan 2014 11:01: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: Thu, 09 Jan 2014 16:01:01 +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.1389283221825 (code B ref 16334); Thu, 09 Jan 2014 16:01:01 +0000 Original-Received: (at 16334) by debbugs.gnu.org; 9 Jan 2014 16:00:21 +0000 Original-Received: from localhost ([127.0.0.1]:44049 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1I1s-0000DC-0N for submit@debbugs.gnu.org; Thu, 09 Jan 2014 11:00:20 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:2387) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1I1k-0000Cw-8a for 16334@debbugs.gnu.org; Thu, 09 Jan 2014 11:00:13 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFFxKG9/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kCogUBsEtkQoDiGGcGYFegxU X-IPAS-Result: Av8EABK/CFFFxKG9/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kCogUBsEtkQoDiGGcGYFegxU X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="44564260" 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; 09 Jan 2014 11:00:10 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id D6D8A603C4; Thu, 9 Jan 2014 11:00:10 -0500 (EST) In-Reply-To: <52CE3FE3.4080503@yandex.ru> (Dmitry Gutov's message of "Thu, 09 Jan 2014 10:21:23 +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:83193 Archived-At: >>> On the other hand, the backend is free to try all completion styles it >> The backends know nothing about completion styles. > Yes, but is this the best approach? I see you're taking advantage of > completion-regexp-list' and the fact that `all-completions' is implemented > in C in `completion-pcm--all-completions', but if one would > implement a completion function using an external service, in many cases > this would mean a non-optimal amount of data to have to be transferred. That's true. That function could make use of completion-regexp-list, but maybe it can't support full regexps (and even if it can, it then requires translating Emacs regexps to the format used by the external tool). This is a limitation inherited from the "original" completion infrastructure. We could easily introduce a replacement for completion-regexp-list which specifies a "pattern" (in a format to be defined). This said, even if the external service can't just take an Emacs regexp, the completion function can parse the regexp from completion-regexp-list and turn it into a different/simpler pattern. > And a service's implementation of different completion styles could be just > as fast, if not faster. Of course, it's only interesting if it's faster, otherwise, why bother? Stefan