From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: Emacs completion matches selection UI Date: Sun, 05 Jan 2014 08:08:28 +0400 Message-ID: <52C8DABC.4090503@yandex.ru> References: <20140102225831.GA19682@c3po> <52C7744F.3000906@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 1388894927 12779 80.91.229.3 (5 Jan 2014 04:08:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 Jan 2014 04:08:47 +0000 (UTC) Cc: Toby Cubitt , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 05 05:08:53 2014 Return-path: Envelope-to: ged-emacs-devel@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 1Vzf1A-0003cl-3d for ged-emacs-devel@m.gmane.org; Sun, 05 Jan 2014 05:08:52 +0100 Original-Received: from localhost ([::1]:56568 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vzf19-0003za-8R for ged-emacs-devel@m.gmane.org; Sat, 04 Jan 2014 23:08:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46846) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vzf0y-0003zT-Nt for emacs-devel@gnu.org; Sat, 04 Jan 2014 23:08:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vzf0q-00084k-9Q for emacs-devel@gnu.org; Sat, 04 Jan 2014 23:08:40 -0500 Original-Received: from mail-lb0-x22e.google.com ([2a00:1450:4010:c04::22e]:56356) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vzf0q-000842-2B for emacs-devel@gnu.org; Sat, 04 Jan 2014 23:08:32 -0500 Original-Received: by mail-lb0-f174.google.com with SMTP id y6so9097940lbh.33 for ; Sat, 04 Jan 2014 20:08:30 -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=B5xZ1++5nI4j2H+4cF6bi0JaYm/qxOgPjA6kyO6G+c0=; b=OWUOkYPBdy49ulWdujWZYGdiOzx4/xnIJmEG7Wy/pgUWUFYiPTCKyJUbyg1I0yjcKb J/w30xER7rRRKzXJXTS2I64cGVunLDxMmSqgB5012DW3ZKfEIBZErjax62RhOMctCUiD hTEGMR6wra1zeyrLICdtE7CJ2mt+DHJb360c3HQfD2vX9B0ejIcMGLxKOhkyqNOKf/B/ wx6OoTJs/P3IufhJdGfF78OeKm1Qv3BOhuunedH8kag0QUvAdreGgMzUbB2hWFKYJ7y1 igw8cRHrWHoykM7srDXAISZFhcw/vNeMtf4QzfusCWdozy4ajDzJexHcAoVGcO6AzGZ7 8Rtg== X-Received: by 10.112.141.67 with SMTP id rm3mr26001607lbb.31.1388894910531; Sat, 04 Jan 2014 20:08:30 -0800 (PST) Original-Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id dw1sm39872856lbc.4.2014.01.04.20.08.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 Jan 2014 20:08:29 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::22e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:167343 Archived-At: On 04.01.2014 07:54, Stefan Monnier wrote: >> In `company-capf', we iterate though the completion-at-point-functions each >> time. This works, and works well enough, since the "does it fit" code is >> usually fast, but it looks fairly bizarre to me, logically. > > Agreed. It was just "the easy" way to fit it in. Can't we save the last `company--capf-data' value in the `prefix' case? Company only calls the rest of the cases after it, and only when the returned value is non-nil. Since prefix value has to stay fresh, the cached data will also be. > "The right thing" would be to replace company-backends with > completion-at-point-functions. I'm not convinced yet that it's the right thing to do. a) `c-a-p-f' looks less accessible to the end user than `company-backends', and the former isn't even a defcustom. The structure of the latter, on the other hand, is easier to read and modify in users' init files and major mode hooks. The Company backends are also easier to spot among other functions in the packages that contain them. The names of the c-a-p-functions used by e.g. IELM follow no discernible convention. b) There's no direct analog to "merged" Company backends in `completion-at-point-functions'. `company-backends' can contain list values, and `company--multi-backend-adapter' handles the merging of the returned data. I'm also tinkering with the idea to make individual candidates remember the backends they came from (using text properties, most likely), so that we will know which backend's function to use with this candidate. Calling `post-completion' action from the wrong backend would be the best example of how it's currently broken.