From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Emacs completion matches selection UI Date: Mon, 06 Jan 2014 18:38:37 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <871u0kfzpe.fsf@flea.lifelogs.com> References: <878uuxhs5s.fsf@flea.lifelogs.com> <20140104004853.GA14062@c3po> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1389051440 18523 80.91.229.3 (6 Jan 2014 23:37:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Jan 2014 23:37:20 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 07 00:37:26 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 1W0JjY-0000MT-NJ for ged-emacs-devel@m.gmane.org; Tue, 07 Jan 2014 00:37:24 +0100 Original-Received: from localhost ([::1]:38096 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0JjY-0005f7-Ap for ged-emacs-devel@m.gmane.org; Mon, 06 Jan 2014 18:37:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0JjP-0005ex-IA for emacs-devel@gnu.org; Mon, 06 Jan 2014 18:37:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0JjJ-0002h9-RM for emacs-devel@gnu.org; Mon, 06 Jan 2014 18:37:15 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:52676) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0JjJ-0002h2-GT for emacs-devel@gnu.org; Mon, 06 Jan 2014 18:37:09 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1W0JjH-0008Ex-Uw for emacs-devel@gnu.org; Tue, 07 Jan 2014 00:37:07 +0100 Original-Received: from c-98-229-61-72.hsd1.ma.comcast.net ([98.229.61.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Jan 2014 00:37:07 +0100 Original-Received: from tzz by c-98-229-61-72.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 07 Jan 2014 00:37:07 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 97 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-98-229-61-72.hsd1.ma.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:EzdmZ3aklm4AttnL5Bsw7dK5XE0= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:167542 Archived-At: On Sat, 4 Jan 2014 00:48:53 +0000 Toby Cubitt wrote: TC> My feeling is once people decide what it is they want included in TC> Emacs, and what the API should look like, re-purposing (parts of) TC> the Company and/or Completion-UI code bases (maybe others too?) will TC> be a big head start (assuming no copyright assignment roadblocks). Yes, exactly. Those are, in my mind, two cases that should work with the API in order to prove its viability, and then we can try to fit others. >> - 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 :) TC> Indeed. It would be nice to get input from the other completion package TC> authors too (anything.el, auto-complete, icicles...) anything.el became Helm and Thierry has been doing a great job maintaining it. I think he follows emacs-devel but as I mentioned I have my doubts that Helm will fit any completion API. It's very integrated. Maybe Thierry wants to say? TC> Since it's the completion UI that will have to interpret and make use of TC> the extras, one place to start is to think about what additional features TC> the UI might want to provide, beyond selecting from a list of possible TC> completions. TC> Luckily, we have many existing completion frameworks to draw on for TC> inspiration. At the moment, location data and various forms of TC> documentation (e.g. type information in code completion, docstrings, TC> etc.) are the only ones that spring to mind. Add: feedback from frontend to backend (Predictive use case we mentioned, needs API support through callbacks). Pluggable completion frontends (not in the API). Dynamic limiting of completion candidates as characters are typed (not in the API). The backend should be able to provide hints about the data. For instance, "this is a list of ELisp symbols" could look different from "this is a list of installable packages." Also icons are important IMO, based on the hints or the candidates. TC> The keyword arguments to `completion-ui-register-source' are one starting TC> point for seeing what additional properties might be needed, as are the TC> corresponding APIs in Company, auto-complete, etc. Can you or Dmitry compile a list? TC> Also, if we want to allow users to optionally customize the completion UI TC> per-backend (a la Completion-UI), there has to be some way of identifying TC> backends in Customize. This seems necessary to me if the new API is to TC> become the standard way of implementing a completion UI in Emacs. Think TC> minibuffer completion, versus filename completion, versus predictive TC> completion, versus elisp code completion etc, all of which might want to TC> use slightly different UI options. Again, it might be enough to support a TC> :name property (or some such) in the `completion-at-point-functions' TC> PROPS plist. The frontend UI should depend (in my mind) on three things: 1) the invocation context as you showed; 2) the backend-provided hints about the data as a whole; and 3) the backend-provided hints about each completion candidate individually. Does that make sense? Some frontends may ignore some or all of those things, but I think those are the principal axis. I don't know how those three things will be passed to the frontend though, and when. >> - the frontend choices made by the user should be able to feed back into >> the data backend (the "predictive" use case) TC> A few optional hooks/call-backs would very likely be sufficient. Again, TC> the `completion-at-point-functions' PROPS plist would be the obvious TC> place to specify them. OK, this is your use case :) >> - 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). ... TC> (Note that I'm unlikely to have time to code anything myself until TC> March/April, although the feature freeze will likely delay things until TC> about then anyway. I'm happy to help in a more limited way before then, TC> as time allows.) Cool. We seem to be moving towards a specific API, refining the current Emacs internals, which is good. I'd be OK with it looking like completion-ui as long as it was at least somewhat backwards compatible and could support the packages we mentioned. To me, the clearest indication of a good approach would be if both the Emacs core and external packages were able to lose lines of code. Ted