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, 30 Dec 2013 20:47:56 +0000 (UTC) Message-ID: References: <87fvqtg02v.fsf@flea.lifelogs.com> <874n67n450.fsf@flea.lifelogs.com> <87eh5bkxca.fsf@flea.lifelogs.com> <87d2kuzzqj.fsf@uwakimon.sk.tsukuba.ac.jp> <87a9fylusq.fsf@flea.lifelogs.com> <878uvizrwz.fsf@uwakimon.sk.tsukuba.ac.jp> <8761qmkyn1.fsf@flea.lifelogs.com> <87zjnyxdpb.fsf@uwakimon.sk.tsukuba.ac.jp> <87k3f2j7xv.fsf@flea.lifelogs.com> <2518D79A-B9E4-45DF-A403-8330145DFD17@gmail.com> <87eh58j0x3.fsf@flea.lifelogs.com> <87mwjvfrfy.fsf@flea.lifelogs.com> <877gawbhp0.fsf@flea.lifelogs.com> <87pponagzs.fsf@flea.lifelogs.com> <871u13aabr.fsf@flea.lifelogs.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1388443217 29278 80.91.229.3 (30 Dec 2013 22:40:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 30 Dec 2013 22:40:17 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 30 23:40:21 2013 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 1VxlVU-00005X-FL for ged-emacs-devel@m.gmane.org; Mon, 30 Dec 2013 23:40:20 +0100 Original-Received: from localhost ([::1]:59999 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VxlVU-0005qq-3I for ged-emacs-devel@m.gmane.org; Mon, 30 Dec 2013 17:40:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34083) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VxlVL-0005qk-VT for emacs-devel@gnu.org; Mon, 30 Dec 2013 17:40:16 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VxlVH-0006EE-9y for emacs-devel@gnu.org; Mon, 30 Dec 2013 17:40:11 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:41842) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VxlVG-0006D7-VH for emacs-devel@gnu.org; Mon, 30 Dec 2013 17:40:07 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VxlVD-0008Cb-JZ for emacs-devel@gnu.org; Mon, 30 Dec 2013 23:40:03 +0100 Original-Received: from 82-69-78-254.dsl.in-addr.zen.co.uk ([82.69.78.254]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 30 Dec 2013 23:40:03 +0100 Original-Received: from toby-predictive by 82-69-78-254.dsl.in-addr.zen.co.uk with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 30 Dec 2013 23:40:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 103 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: sea.gmane.org User-Agent: Loom/3.14 (http://gmane.org/) X-Loom-IP: 82.69.78.254 (Mozilla/5.0 (X11; Linux i686; rv:26.0) Gecko/20100101 Firefox/26.0) 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:167000 Archived-At: Sorry to arrive late to the party :-) Ted Zlatanov lifelogs.com> writes: > On Mon, 23 Dec 2013 08:42:51 -0500 Stefan Monnier IRO.UMontreal.CA> wrote: > OK, I'll move on. If the new UI proves compelling, users will tell us > they want it supported in their favorite modes :) > > >> As with company-mode, this can be a frontend choice (affecting > >> `display-completion-list', and see below for the suggested > >> `display-list' function). How about a defcustom > >> `completion-ui-frontend' with some choices? > > SM> The general idea of completion-ui was great, yes. > > >> For the user, a new defcustom `completion-ui-preferences'? And for the > >> caller, some kind of plist/alist passed to `completion-at-point' that > >> merges cleanly with `completion-ui-preferences'? > > SM> Could be. Tho as mentioned before, I'm not sure that there's a need for > SM> caller-provided preferences. > > OK, I'll work on this off-list to keep the noise down, I've generated > enough emacs-devel traffic so far! > > Dmitry, Stephen, please let me know directly if you want to participate > in the design of `completion-ui-*' as described here. I honestly can't > keep track of all the completion packages available, but I'm > xposting/CC-ing the Helm developers, and Toby Cubitt (because of > http://www.emacswiki.org/emacs/CompletionUI the prefix "completion-ui" > may need to be changed, but it seems to have similar ideas to the > frontends we're describing here). I'm wondering how much of what you're planning has already been coded long ago in completion-UI, which already: - has completely modularised completion user-interfaces, which can be used in any combination the user likes (within reason) - comes with all the UIs people usually ask for: in-buffer text completion, tooltips (both real tooltips, and the "pop-up tip" overlay-based tooltips), drop-down menus, pop-up mini-frames, list of completions in echo area, hotkeys to select completions... - lets you add a new completion UI with a single call to the `completion-ui-register-interface' macro - has completely modularised completion sources (similar to company-mode, anything.el, auto-complete-mode, etc.) - lets you register a new completion source with a single call to the `completion-ui-register-source' macro - defines an `auto-completion-mode' (essentially, a more advanced version of auto-complete.el) that works with any completion source - lets users customize their completion UIs at as fine-grained a level as they want: globally, separately for different completion sources, or (of course) per-major-mode etc. as usual I haven't had time to read the whole thread, but from what I've skimmed through so far it looks like much what you're discussing is already implemented. Completion-UI isn't another company-mode or anything or auto-complete-mode. It was always intended to be "plumbing": a generic completion user-interface toolkit that other packages could use, to unify the interface for selecting completions in Emacs. It would, I think, be rather easy to modify company-mode, auto-complete-mode, anything.el, etc. to use completion-UI instead of their built-in UI code. Many years ago (pre-Stefan's tenure), I had an email discussion with Richard Stallman about getting completion-UI into a state to be added to Emacs, precisely to be a richer generic completion user interface for Emacs. Richard pronounced himself "happy" at the end of the discussion, but then he moved on to other things and I got busy with academic work, and it never happened. If you're interested in exploring how much is already there to be reused or adapted, I'm happy to help (to the extent that my "real" work allows). All the best, Toby PS: If it ever came to that point, I already have copyright papers on file with the FSF, so donating most of the completion-UI code would be straightforward. I use (a slightly modified version of) Tomohiro Matsuyama's popup.el library for the overlay-based tooltips. I don't know if Tomohiro has papers on file. But since the UIs are completely modular, in the worst case that UI could be left out initially, and reimplemented later. -- Dr T. S. Cubitt Royal Society University Research Fellow and Fellow of Churchill College, Cambridge Centre for Quantum Information DAMTP, University of Cambridge email: toby@dr-qubit.org web: www.dr-qubit.org