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: Fri, 10 Jan 2014 10:23:56 +0400 Message-ID: <87vbxs73sz.fsf@yandex.ru> 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 1389335117 629 80.91.229.3 (10 Jan 2014 06:25:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jan 2014 06:25:17 +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 Fri Jan 10 07:25:23 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 1W1VX0-0005FD-KQ for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Jan 2014 07:25:22 +0100 Original-Received: from localhost ([::1]:55481 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1VWz-0001ar-Tu for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Jan 2014 01:25:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38829) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1VWr-0001aW-A4 for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2014 01:25:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1VWh-0006uQ-21 for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2014 01:25:13 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:58861) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1VWg-0006ta-UM for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2014 01:25:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1W1VWf-0002JG-Kj for bug-gnu-emacs@gnu.org; Fri, 10 Jan 2014 01:25: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: Fri, 10 Jan 2014 06:25: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.13893350508781 (code B ref 16334); Fri, 10 Jan 2014 06:25:01 +0000 Original-Received: (at 16334) by debbugs.gnu.org; 10 Jan 2014 06:24:10 +0000 Original-Received: from localhost ([127.0.0.1]:44646 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1VVp-0002HZ-TQ for submit@debbugs.gnu.org; Fri, 10 Jan 2014 01:24:10 -0500 Original-Received: from mail-lb0-f169.google.com ([209.85.217.169]:43132) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W1VVn-0002HO-69 for 16334@debbugs.gnu.org; Fri, 10 Jan 2014 01:24:08 -0500 Original-Received: by mail-lb0-f169.google.com with SMTP id q8so86617lbi.28 for <16334@debbugs.gnu.org>; Thu, 09 Jan 2014 22:24:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=/owdB4dCIjNuA+cjnsQSaLzcDbudYy6C27WJybbsGOw=; b=oxPGPmQZZDFcpYs8GDJpqEpazTIKjVQnVS75yPRVdjcRhMHYHdlB1YLbZ9k5A5+L1m JGWiQtlguYFXSLljJKIApO9HvMmVpbzdHIEFJLobvRUAv/GNOCXniNUM7jtdDaoinq0b 1GNsExXp0uyXUC+pcU6QDAGIgpz7o6bJUoQrYd3rzOREpFgnBjM9zlcIzurqfXbHss25 Nt1YNPxg2Ypw6F2HWtwVN90aOBXUa3uLkBJ0zbqh64UT6mEZpaFVs1HsPj/XdpZXSjsc +JE7j2qseYmq0t5E2mjLUg4og4AqzAoyGXw4VDM509VWdHUx9Zh/w6yzUliMNz2e5AZX KBRA== X-Received: by 10.112.12.229 with SMTP id b5mr1291973lbc.90.1389335046036; Thu, 09 Jan 2014 22:24:06 -0800 (PST) Original-Received: from axl ([178.252.98.87]) by mx.google.com with ESMTPSA id sd11sm3459609lab.2.2014.01.09.22.24.04 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 09 Jan 2014 22:24:05 -0800 (PST) In-Reply-To: (Stefan Monnier's message of "Thu, 09 Jan 2014 11:00:10 -0500") 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:83214 Archived-At: Stefan Monnier writes: > 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). A list of segments would a natural choice, but I was thinking about a more radical change: allowing backends to handle the completion styles. At the moment, `completion--nth-completion' tries all allowed styles, and returns the candidates for the first style that succeeds. 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 We could tell the backends about accepted styles (maybe it would be in their metadata if they can handle styles on their own), and then trust them to return appropriate results. 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. Or maybe require backends to hand over that information. >> 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? Even if the filtering speed is about the same, speedup can come from less time spent serializing/deserializing the full candidates list. And, if we want to return results from different styles together, from making less network calls, and from not forcing the backend to do any preprocessing required by completion code multiple times.