From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Toby Cubitt Newsgroups: gmane.emacs.devel Subject: Re: Emacs completion matches selection UI Date: Mon, 6 Jan 2014 05:25:16 +0000 Message-ID: <20140106052516.GA23077@c3po> References: <52CA303E.7080503@yandex.ru> Reply-To: Toby Cubitt NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1388985937 23827 80.91.229.3 (6 Jan 2014 05:25:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Jan 2014 05:25:37 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 06 06:25:43 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 1W02h3-0000c4-Uz for ged-emacs-devel@m.gmane.org; Mon, 06 Jan 2014 06:25:42 +0100 Original-Received: from localhost ([::1]:60760 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W02h3-0006Nu-DC for ged-emacs-devel@m.gmane.org; Mon, 06 Jan 2014 00:25:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45525) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W02gp-0006Nn-Iw for emacs-devel@gnu.org; Mon, 06 Jan 2014 00:25:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W02gk-0000dU-Vs for emacs-devel@gnu.org; Mon, 06 Jan 2014 00:25:27 -0500 Original-Received: from sanddollar.geekisp.com ([216.168.135.167]:12367) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1W02gk-0000dQ-S3 for emacs-devel@gnu.org; Mon, 06 Jan 2014 00:25:22 -0500 Original-Received: (qmail 15699 invoked by uid 1003); 6 Jan 2014 05:25:22 -0000 Original-Received: from localhost (localhost.geekisp.com [127.0.0.1]) by localhost.geekisp.com (tmda-ofmipd) with ESMTP; Mon, 06 Jan 2014 00:25:18 -0500 Content-Disposition: inline In-Reply-To: <52CA303E.7080503@yandex.ru> X-PGP-Key: http://www.dr-qubit.org/gpg-toby-pub.asc User-Agent: Mutt/1.5.22 (2013-10-16) X-Delivery-Agent: TMDA/1.1.11 (Ladyburn) X-Primary-Address: toby@dr-qubit.org X-detected-operating-system: by eggs.gnu.org: OpenBSD 4.x-5.x [fuzzy] X-Received-From: 216.168.135.167 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:167446 Archived-At: On Mon, Jan 06, 2014 at 08:25:34AM +0400, Dmitry Gutov wrote: > 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. We could allow the COLLECTION argument to be a list of collections, that then get merged by completion-at-point. I agree it's 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?) Presumably the user's supposed to write a function that returns whichever capf they want to use, and add it to the c-a-p-f hook. Or, brainstorming here, you could have a Company customization option that lets them specify a backend preference order (including lists of merged backends), and add a function to the c-a-p-f hook that chooses the best applicable backend. (Though I guess this is essentially bypassing c-a-p-f and substituting it with company-backends.) My feeling is `completion-at-point-functions' is in principle general enough to allow everything we want. But it's seriously creaking at the seams. And it's only likely to get worse as we extend the PROPS argument to cope with a richer set of UIs than the *Completions* buffer. > > 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". In Completion-UI, the "users don't change it" and "users customize it" parts of the definitions are cleanly separated: the `completion-ui-source-definitions' variable, which is modified by calling the `completion-ui-register-source' macro from Elisp code to add a new backend definition; and the `auto-completion-source-regexps', `auto-completion-source-faces' and `auto-completion-source-functions' variables, which have simple Customization interfaces. c-a-p-f doesn't cleanly separate the things users might want to customize, from the things only Elisp completion package authors should have to deal with. > > If Company had started with completion-at-point-functions it would > > live very happily with it. > > That's possible. Or it would have been straining the limits of completion-at-point-functions without company-backends to fall back on, and c-a-p-f would have been extended until it looked more like company-backends ;-) T. -- Dr T. S. Cubitt Royal Society University Research Fellow and Fellow of Churchill College, Cambridge Centre for Quantum Information DAMTP, University of Cambridge email: tsc25@cantab.net web: www.dr-qubit.org