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: Sat, 4 Jan 2014 00:48:53 +0000 Message-ID: <20140104004853.GA14062@c3po> References: <878uuxhs5s.fsf@flea.lifelogs.com> 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 1388796561 7730 80.91.229.3 (4 Jan 2014 00:49:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 Jan 2014 00:49:21 +0000 (UTC) Cc: Dmitry Gutov , Stefan Monnier , emacs-devel@gnu.org To: Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 04 01:49:28 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 1VzFQZ-0003DC-W9 for ged-emacs-devel@m.gmane.org; Sat, 04 Jan 2014 01:49:24 +0100 Original-Received: from localhost ([::1]:52713 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzFQZ-0001Zd-L3 for ged-emacs-devel@m.gmane.org; Fri, 03 Jan 2014 19:49:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36614) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzFQS-0001Wg-QG for emacs-devel@gnu.org; Fri, 03 Jan 2014 19:49:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VzFQO-00016V-MN for emacs-devel@gnu.org; Fri, 03 Jan 2014 19:49:16 -0500 Original-Received: from starfish.geekisp.com ([216.168.135.166]:48855) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1VzFQO-00016R-Hl for emacs-devel@gnu.org; Fri, 03 Jan 2014 19:49:12 -0500 Original-Received: (qmail 6100 invoked by uid 1003); 4 Jan 2014 00:49:11 -0000 Original-Received: from localhost (localhost.geekisp.com [127.0.0.1]) by localhost.geekisp.com (tmda-ofmipd) with ESMTP; Fri, 03 Jan 2014 19:49:08 -0500 Content-Disposition: inline In-Reply-To: <878uuxhs5s.fsf@flea.lifelogs.com> 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.166 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:167243 Archived-At: Thanks for the great summary, Ted! On Fri, Jan 03, 2014 at 12:49:35PM -0500, Ted Zlatanov wrote: > On Thu, 02 Jan 2014 13:10:11 -0500 Stefan Monnier wrote: > > SM> I'd love to see company-mode and completion-ui consolidated into Emacs's > SM> core code. The "completion sources" would be provided via > SM> completion-at-point-functions, so we already have a place for > SM> that part. We don't yet have an API for the "completion UI > SM> frontend", OTOH, so if we can agree on a good API for that part, we > SM> could restructure the minibuffer.el code around that and then add > SM> more UIs. > > Based on the discussion so far, it seems that: > > - there are good use cases for both completion-ui and company-mode, we > can't claim either is a superset of the other. The two are not > fundamentally incompatible. Agreed. My feeling is once people decide what it is they want included in Emacs, and what the API should look like, re-purposing (parts of) the Company and/or Completion-UI code bases (maybe others too?) will be a big head start (assuming no copyright assignment roadblocks). > - I personally used company-mode heavily in the last few weeks and it > works great, but I don't like that after a timeout, the up/down keys > get taken over. I think displaying the completion candidates could > happen after a timeout, but selecting from them should happen only > when the user explicitly requests it with M-TAB in a buffer or TAB in > the minibuffer. This is a minor detail, which I'm sure would be trivial to change in Company if so desired. (Wouldn't surprise me if it can already be disabled by rebinding keys in company-mode keymaps.) If you enable a `completion-auto-show' interface and `completion-auto-show-delay' (both enabled by default), Completion-UI behaves in exactly the same way as Company. People seem to expect the up/down keys to cycling through completions when they're displayed in a tooltip - I got bug reports before I implemented it. > - it should be possible to implement a generic frontend for completion > that both can use, and other tools like yasnippet can use IIUC. The > eventual goal is to have "something" standard in Emacs that all such > packages (except perhaps helm, which is completely apart in its UI) > would use. We have to ask Dmitry and Toby, among others, to guide us > with their experience of writing it once already, and we have to make > sure we don't end up with a solution no one wants to use :) Indeed. It would be nice to get input from the other completion package authors too (anything.el, auto-complete, icicles...) > - the backend data should be able to carry more than plain strings, > things like docstrings and such, and IMO we should try to standardize > the possible extras at least somewhat. Agreed. Since it's the completion UI that will have to interpret and make use of the extras, one place to start is to think about what additional features the UI might want to provide, beyond selecting from a list of possible completions. Luckily, we have many existing completion frameworks to draw on for inspiration. At the moment, location data and various forms of documentation (e.g. type information in code completion, docstrings, etc.) are the only ones that spring to mind. > We may need a deeper backend abstraction than > `completion-at-point-functions' because of this. It might be sufficient to extend the list of supported properties in the `completion-at-point-functions' PROPS plist. The keyword arguments to `completion-ui-register-source' are one starting point for seeing what additional properties might be needed, as are the corresponding APIs in Company, auto-complete, etc. Also, if we want to allow users to optionally customize the completion UI per-backend (a la Completion-UI), there has to be some way of identifying backends in Customize. This seems necessary to me if the new API is to become the standard way of implementing a completion UI in Emacs. Think minibuffer completion, versus filename completion, versus predictive completion, versus elisp code completion etc, all of which might want to use slightly different UI options. Again, it might be enough to support a :name property (or some such) in the `completion-at-point-functions' PROPS plist. > - the frontend choices made by the user should be able to feed back into > the data backend (the "predictive" use case) A few optional hooks/call-backs would very likely be sufficient. Again, the `completion-at-point-functions' PROPS plist would be the obvious place to specify them. > - we have enough interest and support in this work that it's worth > undertaking in earnest after the code freeze. The discussion should > remain on emacs-devel (based on the wide interest so far). At the moment, it sounds to me like the existing `completion-at-point-functions' and `completion-at-point' / `completion-in-region' APIs could be extended to provide a more "modern", richer, and customizable generic Emacs completion UI. Then minibuffer completion, Company, Predictive, anything, etc. could all eventually be converted to use this. > I hope everyone agrees. Sounds good to me. (Note that I'm unlikely to have time to code anything myself until March/April, although the feature freeze will likely delay things until about then anyway. I'm happy to help in a more limited way before then, as time allows.) Toby -- 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