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: Mon, 06 Jan 2014 08:25:34 +0400 Message-ID: <52CA303E.7080503@yandex.ru> References: <20140102225831.GA19682@c3po> <52C7744F.3000906@yandex.ru> <52C8DABC.4090503@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 1388982419 25065 80.91.229.3 (6 Jan 2014 04:26:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Jan 2014 04:26:59 +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 Mon Jan 06 05:27:05 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 1W01mL-0003o0-2U for ged-emacs-devel@m.gmane.org; Mon, 06 Jan 2014 05:27:05 +0100 Original-Received: from localhost ([::1]:60615 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W01mK-0004mV-L4 for ged-emacs-devel@m.gmane.org; Sun, 05 Jan 2014 23:27:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38649) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W01l6-0002sX-Tb for emacs-devel@gnu.org; Sun, 05 Jan 2014 23:25:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W01ky-0004Cj-Ei for emacs-devel@gnu.org; Sun, 05 Jan 2014 23:25:48 -0500 Original-Received: from mail-lb0-x22f.google.com ([2a00:1450:4010:c04::22f]:63397) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W01kx-0004CL-3c for emacs-devel@gnu.org; Sun, 05 Jan 2014 23:25:39 -0500 Original-Received: by mail-lb0-f175.google.com with SMTP id w6so9432127lbh.20 for ; Sun, 05 Jan 2014 20:25:37 -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=dxP5BSX7YgLuuELLXF5kLXQ2vUF4GbbLUMijSym14zg=; b=GR+zKGs583k4VIj8eB8R2Byb/wtO+hcQTWfWCMAUDz9TSwSblrwLr4rgyFgUpTDV+8 2EIN1xeHHgnr8R1L7SGwpT7UG0oSGtW6DS+DjUSmH38KNqzjOm5iKiVv0x147jibchTt H+NuZwVFrVyItodX+Xzw9nAvYbDAD1TBBvcpZTJ8wO5vVmn8ktHoT/CRqSQg2XYfBEbX OeRJx/F45+xVSMcA4dPi3m9J+ZjzOzkrsSCGMQ6KHeFlTdaCOUayBw71V8jKgeH5oYUj JKZBtf4FStaWQKoxMysz2kUkp0za6HMjaW9wC5bT8s3fMjtU+37yJcoPUU4DphUfEjD+ zesQ== X-Received: by 10.112.92.112 with SMTP id cl16mr41024019lbb.15.1388982337598; Sun, 05 Jan 2014 20:25:37 -0800 (PST) Original-Received: from [192.168.1.3] ([178.252.98.87]) by mx.google.com with ESMTPSA id j1sm41906440lbl.10.2014.01.05.20.25.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 05 Jan 2014 20:25:36 -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::22f 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:167441 Archived-At: On 05.01.2014 20:04, Stefan Monnier wrote: >> a) `c-a-p-f' looks less accessible to the end user than `company-backends', > > That's because it's mostly not meant for the users to change, and that's > because users should not need to touch it. I disagree. Two examples: 1. I'm planning to write a new backend that would integrate with Yasnippet. But it's not particularly useful as a stand-alone completion function, because when the user types "if", they might want to either expand it to "if (...) { }", or, for example, call a function whose name starts with "if", and they should see both options. In Company terms, that means that those backends should be merged: the first item in `company-backends' will be a list with the names of these two backends (or maybe more). Doing this programmatically for the user could be fairly surprising, and, in the case of `c-a-p-f', opaque. 2. We have two backends that are applicable in a similar set of major modes: company-semantic and company-clang. We can check if we can use either (by seeing if Semantic is enabled and by looking for the Clang program), but if both are usable, user might want to prefer to use the one or the other. How to let them pick? Providing a couple of minor modes, where each would only enable/disable a specific backend/capf is possible, but very clunky, as far as I'm concerned, and requires special treatment. (Do I provide a minor mode for this backend function? How about this other one?) > `company-backends' in contrast contains a mishmash of things, 90% of > which is irrelevant to any given situation. That's just the default value. Users can set it to smaller lists in specific major modes to make it more "relevant" if they want, but the relevancy check is fast, so by default the list is global and is indeed a mishmash, to make getting started easier. > Nothing prevents us from providing > a "completion-at-point-merge-backends" function which takes a list of > completion-at-point-functions and returns a new completion-at-point-function. Indeed. Although it seems to me that remembering where each candidate came from (feature not yet present in Company either) would be harder to implement, because completion functions are pretty much nameless as far as the code using them is concerned. So propertizing the candidates with (backend . company-elisp) won't work like it would in Company. > company-backends and completion-at-point-functions don't work 100% > identically, but the differences are present only because of history. I believe the main difference is "users customize it" vs. "users generally don't know how to change it". > If Company had started with completion-at-point-functions it would live > very happily with it. That's possible.