From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 03 18:20:47 2014 Received: (at submit) by debbugs.gnu.org; 3 Jan 2014 23:20:47 +0000 Received: from localhost ([127.0.0.1]:60719 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VzE2p-0006bE-02 for submit@debbugs.gnu.org; Fri, 03 Jan 2014 18:20:47 -0500 Received: from eggs.gnu.org ([208.118.235.92]:48550) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VzE2n-0006b4-CO for submit@debbugs.gnu.org; Fri, 03 Jan 2014 18:20:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VzE2h-0003TN-9c for submit@debbugs.gnu.org; Fri, 03 Jan 2014 18:20:45 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_05,FREEMAIL_FROM, T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:50790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzE2h-0003TI-5n for submit@debbugs.gnu.org; Fri, 03 Jan 2014 18:20:39 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50251) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzE2b-0003WD-Au for bug-gnu-emacs@gnu.org; Fri, 03 Jan 2014 18:20:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VzE2V-0003S2-D5 for bug-gnu-emacs@gnu.org; Fri, 03 Jan 2014 18:20:33 -0500 Received: from mail-lb0-x22d.google.com ([2a00:1450:4010:c04::22d]:60768) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzE2U-0003Qu-Rn for bug-gnu-emacs@gnu.org; Fri, 03 Jan 2014 18:20:27 -0500 Received: by mail-lb0-f173.google.com with SMTP id z5so8511001lbh.18 for ; Fri, 03 Jan 2014 15:20:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:subject:date:message-id:mime-version:content-type; bh=er0b752/Zed5lq7xcU9CJsIj2XF9CBafzfsE+UPh0ns=; b=t1w7DQ54cGQJdiAl0q+hD/cOGEUOq14qjoV55+9DO33rXh+qYO7xEaDTkRXN+JBQ3p TIf2WQO1N2wFcmia2yyJmaq9I4ntNx1nhTaayeL4Nz/crfd/ghxg3F3u4B+zLIpvzc4D mdTGR3KmB3HAGv5huw439xMdc1WX0L8cNtzOCM2R4BFiZUM5EHATRK+vgRCe769XNihC +Fw73MXaDbYg2fdlpbJCrHEkD2tbCyiEc1WdNcPsAaO89FIjWXDKYTtnkAKHWwdXavNt lqz6D59GaDxMJ5Ihgzaq38u3jI+ZHM8bD6F7Ye0ZdfSLuqM3h8YfOdq50sKr763Bwas4 opGw== X-Received: by 10.152.26.72 with SMTP id j8mr17987lag.85.1388791225815; Fri, 03 Jan 2014 15:20:25 -0800 (PST) Received: from axl ([79.173.102.119]) by mx.google.com with ESMTPSA id mv9sm37428134lbc.0.2014.01.03.15.20.23 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 03 Jan 2014 15:20:25 -0800 (PST) From: Dmitry Gutov To: bug-gnu-emacs@gnu.org Subject: 24.3.50; company-capf eats the first char in IELM filename completions Date: Sat, 04 Jan 2014 03:20:17 +0400 Message-ID: <87sit4ejpq.fsf@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.0 (----) 1. Open an IELM buffer and (on Unix) type `"/' there. 2. Leave the point after `/'. 3. Type `M-x company-capf', see that all candidates have the first character missing. This is caused by `(comint--match-partial-filename)' matching the full file path, including the leading slash, but `comint-completion-file-name-table' returning base names, without any path separators. Not sure how `completion-at-point' ignores that problem. Bonus round: 4. Type `/u', see the suggestion to complete it to `/ur/'. 5. Type `/usr/', then `M-x company-capf', see an error caused by some candidates being shorter than the prefix. In GNU Emacs 24.3.50.4 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.6) of 2014-01-04 on axl Bzr revision: 115859 vincentb1@users.sourceforge.net-20140103141824-juu968y9pi6r2zvv Windowing system distributor `The X.Org Foundation', version 11.0.11403000 System Description: Ubuntu 13.10 From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 04 00:00:46 2014 Received: (at 16334) by debbugs.gnu.org; 4 Jan 2014 05:00:46 +0000 Received: from localhost ([127.0.0.1]:32818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VzJLq-0000E6-EQ for submit@debbugs.gnu.org; Sat, 04 Jan 2014 00:00:46 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:37907) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VzJLo-0000Dx-Gz for 16334@debbugs.gnu.org; Sat, 04 Jan 2014 00:00:44 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFG4rwsm/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IPAS-Result: Av8EABK/CFG4rwsm/2dsb2JhbABEuzWDWRdzgh4BAQQBViMFCwsOJhIUGA0kiB4GwS2RCgOIYZwZgV6DFQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="43948725" Received: from 184-175-11-38.dsl.teksavvy.com (HELO pastel.home) ([184.175.11.38]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 04 Jan 2014 00:00:43 -0500 Received: by pastel.home (Postfix, from userid 20848) id A4FA06063D; Sat, 4 Jan 2014 00:00:43 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#16334: 24.3.50; company-capf eats the first char in IELM filename completions Message-ID: References: <87sit4ejpq.fsf@yandex.ru> Date: Sat, 04 Jan 2014 00:00:43 -0500 In-Reply-To: <87sit4ejpq.fsf@yandex.ru> (Dmitry Gutov's message of "Sat, 04 Jan 2014 03:20:17 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 16334 Cc: 16334@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > 1. Open an IELM buffer and (on Unix) type `"/' there. > 2. Leave the point after `/'. > 3. Type `M-x company-capf', see that all candidates have the first > character missing. That's normal. Try C-x C-f / TAB TAB and you'll see that the leading / is also "missing" in the *Completions* buffer. > Not sure how `completion-at-point' ignores that problem. It doesn't ignore the problem. It knows that (all-completions STR TABLE) doesn't always return strings that have STR as a prefix and spends a fair bit of effort handling it right. > 5. Type `/usr/', then `M-x company-capf', see an error caused by some > candidates being shorter than the prefix. Indeed, Company can't handle all completion-at-point-functions so far because it assumes all completion tables are "simple", unlike for example filename completion. You can know how many chars are "missing" by calling `completion-boundaries'. Ideally, Company should be extended to handle this feature, but for now that can be handled in company-capf. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 04 21:21:06 2014 Received: (at 16334) by debbugs.gnu.org; 5 Jan 2014 02:21:06 +0000 Received: from localhost ([127.0.0.1]:34793 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VzdKr-0004yz-P1 for submit@debbugs.gnu.org; Sat, 04 Jan 2014 21:21:06 -0500 Received: from mail-la0-f42.google.com ([209.85.215.42]:37667) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VzdKp-0004yZ-1w for 16334@debbugs.gnu.org; Sat, 04 Jan 2014 21:21:03 -0500 Received: by mail-la0-f42.google.com with SMTP id ec20so9075055lab.15 for <16334@debbugs.gnu.org>; Sat, 04 Jan 2014 18:21:01 -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=MGQbPs1mF90FdjICX0tpjCH7xORnjgPK+OIabZWC1tY=; b=azl5qIRx0+m5osUdgOJ5dAl8TFkzgohU2RS3DEQ48fMnnQvFFm2O0dcmdPgz4KsFDL mqNzwORt6vjDrSASTfl3hoPFijbOJCf19w+LXyqnoPr6gxR2wZw+vhbL9x/kz7VqJCGj U/hEqVbag0rBFB9/ZhX5x9Xmok/5WFC/2weAphPHKAO3N3NdMOLbotLiYrTBtLR2h7ah y1mAHwCYPLVepuI4fypinQi9lYSo8ZkJDYaBA6IY/pzWmuRJnOvO0TBd0+el19drRqr2 4zlMDI77Xi8aNz5+NXGoREuDAa8Epi/68fBAAHyP7ZeXKWTXepI4E0X3XrAuV8AlixQ9 LMqg== X-Received: by 10.152.87.37 with SMTP id u5mr40383164laz.11.1388888461583; Sat, 04 Jan 2014 18:21:01 -0800 (PST) Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id sd11sm51100646lab.2.2014.01.04.18.21.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 Jan 2014 18:21:00 -0800 (PST) Message-ID: <52C8C18A.3010501@yandex.ru> Date: Sun, 05 Jan 2014 06:20:58 +0400 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stefan Monnier Subject: Re: bug#16334: 24.3.50; company-capf eats the first char in IELM filename completions References: <87sit4ejpq.fsf@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16334 Cc: 16334@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 04.01.2014 09:00, Stefan Monnier wrote: > That's normal. Try C-x C-f / TAB TAB and you'll see that the leading / > is also "missing" in the *Completions* buffer. > ... > Indeed, Company can't handle all completion-at-point-functions so far > because it assumes all completion tables are "simple", unlike > for example filename completion. > > You can know how many chars are "missing" by calling > `completion-boundaries'. Thanks, I didn't know about that. > Ideally, Company should be extended to handle this feature, It's not hard to do, but are you sure it would be a good addition to the API? "Completion prefix" and "completion bounds" are easy to mix up, and from what I see in various completion mechanisms, the non-simple completion tables more often need to look at the whole buffer before point, or at least a large chunk of it. `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 for now that can be handled in company-capf. Ok, I'll try. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 04 22:17:07 2014 Received: (at 16334-done) by debbugs.gnu.org; 5 Jan 2014 03:17:07 +0000 Received: from localhost ([127.0.0.1]:34849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VzeD4-0006Vh-9Y for submit@debbugs.gnu.org; Sat, 04 Jan 2014 22:17:06 -0500 Received: from mail-lb0-f172.google.com ([209.85.217.172]:39887) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VzeD2-0006VZ-1q for 16334-done@debbugs.gnu.org; Sat, 04 Jan 2014 22:17:04 -0500 Received: by mail-lb0-f172.google.com with SMTP id x18so9048644lbi.17 for <16334-done@debbugs.gnu.org>; Sat, 04 Jan 2014 19:17:03 -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=xjcyDd7xUg2Uk06c/0wm1W1VpeFOWqol4VgKwQI+Jkk=; b=e++o51woCrgZ7MHb2DwSu7CME8q2WBZYtH0vGxOFtR1pIYUBtUTCxbty5nR1ymYo28 gLsw8OtsD3hEWPau2HqQbL6Z3yPcYoSAKMCyvI0fVO3XEvvZq2XtH1rf0T7hNUJZ9L9Y wk/AzCxkICnzRGK3ZzjqtfVKVQV7Ee2MxyPfLNDrvv3ArF7ziE+66tlZD4R/a6EKmBPy ffwarLCG/Aclu4aqfJiB3/BIClvKWXg0t1uL4CCOv+bOJ6U+9Ki8dnoPBj7Opt+qOxs3 uvbqSx4zDi5/IWeqTbA4CYvoR0VjsdWC2pw45IUKdyVuYA6FhYVzwIqMYl8kswqVyGWl SSng== X-Received: by 10.152.116.46 with SMTP id jt14mr2003190lab.31.1388891822907; Sat, 04 Jan 2014 19:17:02 -0800 (PST) Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id mx3sm39786324lbc.14.2014.01.04.19.17.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 Jan 2014 19:17:01 -0800 (PST) Message-ID: <52C8CEAC.2010602@yandex.ru> Date: Sun, 05 Jan 2014 07:17:00 +0400 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stefan Monnier Subject: Re: bug#16334: 24.3.50; company-capf eats the first char in IELM filename completions References: <87sit4ejpq.fsf@yandex.ru> <52C8C18A.3010501@yandex.ru> In-Reply-To: <52C8C18A.3010501@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16334-done Cc: 16334-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05.01.2014 06:20, Dmitry Gutov wrote: > Ok, I'll try. Fixed upstream. From debbugs-submit-bounces@debbugs.gnu.org Sat Jan 04 23:53:28 2014 Received: (at 16334) by debbugs.gnu.org; 5 Jan 2014 04:53:29 +0000 Received: from localhost ([127.0.0.1]:34935 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VzfiK-0001BN-NI for submit@debbugs.gnu.org; Sat, 04 Jan 2014 23:53:28 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:38012) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VzfiJ-0001BE-1t for 16334@debbugs.gnu.org; Sat, 04 Jan 2014 23:53:27 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFG4rwsm/2dsb2JhbABEuzWDWRdzgh8BBVYjEAsOJhIUGA0kiCTBLZEKA4hhnBmBXoMV X-IPAS-Result: Av8EABK/CFG4rwsm/2dsb2JhbABEuzWDWRdzgh8BBVYjEAsOJhIUGA0kiCTBLZEKA4hhnBmBXoMV X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="44045147" Received: from 184-175-11-38.dsl.teksavvy.com (HELO ceviche.home) ([184.175.11.38]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 04 Jan 2014 23:53:26 -0500 Received: by ceviche.home (Postfix, from userid 20848) id 04233660A5; Sat, 4 Jan 2014 23:53:25 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#16334: 24.3.50; company-capf eats the first char in IELM filename completions Message-ID: References: <87sit4ejpq.fsf@yandex.ru> <52C8C18A.3010501@yandex.ru> Date: Sat, 04 Jan 2014 23:53:25 -0500 In-Reply-To: <52C8C18A.3010501@yandex.ru> (Dmitry Gutov's message of "Sun, 05 Jan 2014 06:20:58 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 16334 Cc: 16334@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > `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. The completion table itself does not know how to do that, but some completion styles do (e.g. partial-completion). So the completion-at-point-function needs to indicate the boundaries of "/u/s/d" which indicate which text can be affected by the completion, while `completion-boundaries' tells the lower-level completion code (e.g. the one in partial-completion) how to split the completion field into sub-fields. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 06 00:33:48 2014 Received: (at 16334) by debbugs.gnu.org; 6 Jan 2014 05:33:48 +0000 Received: from localhost ([127.0.0.1]:37618 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W02ot-0007Ly-JO for submit@debbugs.gnu.org; Mon, 06 Jan 2014 00:33:47 -0500 Received: from mail-lb0-f181.google.com ([209.85.217.181]:62134) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W02or-0007Lm-LV for 16334@debbugs.gnu.org; Mon, 06 Jan 2014 00:33:46 -0500 Received: by mail-lb0-f181.google.com with SMTP id q8so9466912lbi.40 for <16334@debbugs.gnu.org>; Sun, 05 Jan 2014 21:33:44 -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=LUS+g4fcm6HtwkGX8NuPqYxCNwMXzS5671WIOoicUMM=; b=RqsridUgcK7hp2Or4fCct3VI9cR1TCRh7VrzMoqQmNjFlhozMLV5ds6grvSurldO+g 9MKj2EvtF9TGt9mioOeY3ASTplmW7CSg5x5Og8j4K9/3imLv3wNnwJEbxhLyMKjMb1ve umtTf5MQvbv7YbzN8/k+MiCA1lJPme+H4K7otWoEplTzb9LZUNquc4M2HcJm2vfJdhgR OLslI9aB9G4IUG8YLtTe9j7LCGO1Gb5GEUvIVlfZ8lUb59lPKp8kMdp/BkgKnuPYkGPe 8/mYXxH0gPTztMIJvzlx4knaMR5y7fhotoDTIQWOl7+m73Za6JCggZIZAmCVllJd4yuM MZOg== X-Received: by 10.112.151.74 with SMTP id uo10mr209298lbb.45.1388986424430; Sun, 05 Jan 2014 21:33:44 -0800 (PST) Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id np10sm42012626lbb.7.2014.01.05.21.33.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 Jan 2014 21:33:43 -0800 (PST) Message-ID: <52CA4035.2020302@yandex.ru> Date: Mon, 06 Jan 2014 09:33:41 +0400 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stefan Monnier Subject: Re: bug#16334: 24.3.50; company-capf eats the first char in IELM filename completions References: <87sit4ejpq.fsf@yandex.ru> <52C8C18A.3010501@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16334 Cc: 16334@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 05.01.2014 08:53, 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. In that case, "/usr/share/doc" is the completion candidate, not "doc", right? Then, "/u/s/d" can be considered a "generalized" prefix, or the entity to complete, in c-a-p-f terms. And during completion we delete the latter and insert the former. > The completion table itself does not know how to do that, but some > completion styles do (e.g. partial-completion). > So the completion-at-point-function needs to indicate the boundaries of > "/u/s/d" which indicate which text can be affected by the completion, > while `completion-boundaries' tells the lower-level completion code > (e.g. the one in partial-completion) how to split the completion field > into sub-fields. 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. 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. And maybe do the same for suffix boundary, when/if we support that kind of completion. 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. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 06 10:23:22 2014 Received: (at 16334) by debbugs.gnu.org; 6 Jan 2014 15:23:22 +0000 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 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" 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 Received: by pastel.home (Postfix, from userid 20848) id B38B762F43; Mon, 6 Jan 2014 10:23:16 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#16334: 24.3.50; company-capf eats the first char in IELM filename completions Message-ID: References: <87sit4ejpq.fsf@yandex.ru> <52C8C18A.3010501@yandex.ru> <52CA4035.2020302@yandex.ru> Date: Mon, 06 Jan 2014 10:23:16 -0500 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) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 16334 Cc: 16334@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >>> `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 From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 06 21:52:20 2014 Received: (at 16334) by debbugs.gnu.org; 7 Jan 2014 02:52:20 +0000 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 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 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) 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) Message-ID: <52CB6BDB.4020601@yandex.ru> Date: Tue, 07 Jan 2014 06:52:11 +0400 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stefan Monnier Subject: Re: bug#16334: 24.3.50; company-capf eats the first char in IELM filename completions References: <87sit4ejpq.fsf@yandex.ru> <52C8C18A.3010501@yandex.ru> <52CA4035.2020302@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16334 Cc: 16334@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) 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... From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 07 22:33:23 2014 Received: (at 16334) by debbugs.gnu.org; 8 Jan 2014 03:33:23 +0000 Received: from localhost ([127.0.0.1]:41803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W0jtT-0001z8-EY for submit@debbugs.gnu.org; Tue, 07 Jan 2014 22:33:23 -0500 Received: from ironport2-out.teksavvy.com ([206.248.154.181]:58566) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W0jtR-0001yy-PI for 16334@debbugs.gnu.org; Tue, 07 Jan 2014 22:33:22 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFxKG9/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBgyxE5AKBJEKA4hhnBmBXoMV X-IPAS-Result: Av4EABK/CFFFxKG9/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBgyxE5AKBJEKA4hhnBmBXoMV X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="44445917" Received: from 69-196-161-189.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([69.196.161.189]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 07 Jan 2014 22:33:20 -0500 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id B98C7AE233; Tue, 7 Jan 2014 22:33:20 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#16334: 24.3.50; company-capf eats the first char in IELM filename completions Message-ID: References: <87sit4ejpq.fsf@yandex.ru> <52C8C18A.3010501@yandex.ru> <52CA4035.2020302@yandex.ru> <52CB6BDB.4020601@yandex.ru> Date: Tue, 07 Jan 2014 22:33:20 -0500 In-Reply-To: <52CB6BDB.4020601@yandex.ru> (Dmitry Gutov's message of "Tue, 07 Jan 2014 06:52:11 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 16334 Cc: 16334@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >>>>> `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"? There are 2 levels: the level of try-completion, all-completions, an completion-boundaries. At that level, the completion should not affect the text outside of the boundaries. This is the level at which completion-tables operate. Then there's the level of completion-try-completion and completion-all-completions. This uses the info from the previous level to implement completion according to completion-styles. It can change things outside of the boundaries. This is part of the UI, not of the backends. >>> 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? Then "/u/s/d" returns no completion candidates. > Already done: > https://github.com/company-mode/company-mode/compare/b70540b5fcd062c4670dea7004453de326ff4f70...8ecec3594931ae8e2329fec4b793ad4ba392e4ef It's not in elpa yet. > On the other hand, the backend is free to try all completion styles it The backends know nothing about completion styles. > 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... Exactly. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 09 01:21:32 2014 Received: (at 16334) by debbugs.gnu.org; 9 Jan 2014 06:21:32 +0000 Received: from localhost ([127.0.0.1]:43462 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W18zj-0007HO-NR for submit@debbugs.gnu.org; Thu, 09 Jan 2014 01:21:32 -0500 Received: from mail-lb0-f179.google.com ([209.85.217.179]:56305) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1W18zh-0007HD-Gv for 16334@debbugs.gnu.org; Thu, 09 Jan 2014 01:21:30 -0500 Received: by mail-lb0-f179.google.com with SMTP id w7so1959940lbi.24 for <16334@debbugs.gnu.org>; Wed, 08 Jan 2014 22:21:28 -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=AE13V5azgQI6DHUTtXP4uXvnpC9hNYXfliGoq513cDM=; b=Vl9kDhXNp7UglcjPNJIKhudqnV/4rpyHOX1B6p37GR9LXB57H8fvKFVYzGSwwc8tg3 MMUl3Qj72u4ndNt5Lb7eyPxFDgRAJj1m+Nt8r6P+0Y7/NEOCu4sdAX1Fk/ayAgquyGoV 1txw02KtLkpfvf+unLeRiMGbbrywHX+Jk6/lJZSzh7VBXigq1/28CuDgWVw7LG8bQa89 nKNOaqGjjHhKIqvSnbNAE0XYRFMhay0uCch/vcd5otlw5PazKbf/Ett8/2k3w6Cu1El9 8VuCvVKec6ARU94crzuXNwMSPVJc+Qi7xYjP1swhoGIFKkh1onOVZkE00E/XNnBvcvqr iUmQ== X-Received: by 10.112.209.101 with SMTP id ml5mr437772lbc.70.1389248488427; Wed, 08 Jan 2014 22:21:28 -0800 (PST) Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id bo10sm524105lbb.16.2014.01.08.22.21.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Jan 2014 22:21:27 -0800 (PST) Message-ID: <52CE3FE3.4080503@yandex.ru> Date: Thu, 09 Jan 2014 10:21:23 +0400 From: Dmitry Gutov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Stefan Monnier Subject: Re: bug#16334: 24.3.50; company-capf eats the first char in IELM filename completions References: <87sit4ejpq.fsf@yandex.ru> <52C8C18A.3010501@yandex.ru> <52CA4035.2020302@yandex.ru> <52CB6BDB.4020601@yandex.ru> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16334 Cc: 16334@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 08.01.2014 07:33, Stefan Monnier wrote: >> Already done: >> https://github.com/company-mode/company-mode/compare/b70540b5fcd062c4670dea7004453de326ff4f70...8ecec3594931ae8e2329fec4b793ad4ba392e4ef > > It's not in elpa yet. It will be. Users won't get the new version until the header's bumped anyway. >> 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. And a service's implementation of different completion styles could be just as fast, if not faster. Omnisharp has it already, so using it should make sense. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 09 11:00:20 2014 Received: (at 16334) by debbugs.gnu.org; 9 Jan 2014 16:00:21 +0000 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 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" 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 Received: by pastel.home (Postfix, from userid 20848) id D6D8A603C4; Thu, 9 Jan 2014 11:00:10 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#16334: 24.3.50; company-capf eats the first char in IELM filename completions Message-ID: References: <87sit4ejpq.fsf@yandex.ru> <52C8C18A.3010501@yandex.ru> <52CA4035.2020302@yandex.ru> <52CB6BDB.4020601@yandex.ru> <52CE3FE3.4080503@yandex.ru> Date: Thu, 09 Jan 2014 11:00:10 -0500 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) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 16334 Cc: 16334@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) >>> 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 10 01:24:10 2014 Received: (at 16334) by debbugs.gnu.org; 10 Jan 2014 06:24:10 +0000 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 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 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) 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) From: Dmitry Gutov To: Stefan Monnier Subject: Re: bug#16334: 24.3.50; company-capf eats the first char in IELM filename completions References: <87sit4ejpq.fsf@yandex.ru> <52C8C18A.3010501@yandex.ru> <52CA4035.2020302@yandex.ru> <52CB6BDB.4020601@yandex.ru> <52CE3FE3.4080503@yandex.ru> Date: Fri, 10 Jan 2014 10:23:56 +0400 In-Reply-To: (Stefan Monnier's message of "Thu, 09 Jan 2014 11:00:10 -0500") Message-ID: <87vbxs73sz.fsf@yandex.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 16334 Cc: 16334@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 10 09:58:27 2014 Received: (at 16334) by debbugs.gnu.org; 10 Jan 2014 14:58:27 +0000 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 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" 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 Received: by pastel.home (Postfix, from userid 20848) id 2C8056045A; Fri, 10 Jan 2014 09:58:24 -0500 (EST) From: Stefan Monnier To: Dmitry Gutov Subject: Re: bug#16334: 24.3.50; company-capf eats the first char in IELM filename completions 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> Date: Fri, 10 Jan 2014 09:58:24 -0500 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) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 16334 Cc: 16334@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) > 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 From unknown Mon Jun 23 13:10:10 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 08 Feb 2014 12:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator