From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Emacs completion matches selection UI Date: Sat, 21 Dec 2013 12:32:19 +0900 Message-ID: <87wqiyop4s.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87fvqtg02v.fsf@flea.lifelogs.com> <8761rkaa5e.fsf@flea.lifelogs.com> <87txf0390n.fsf@flea.lifelogs.com> <87y53komex.fsf@flea.lifelogs.com> <87haa8moh6.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1387596822 17859 80.91.229.3 (21 Dec 2013 03:33:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Dec 2013 03:33:42 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 21 04:33:47 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 1VuDJy-0007yW-3a for ged-emacs-devel@m.gmane.org; Sat, 21 Dec 2013 04:33:46 +0100 Original-Received: from localhost ([::1]:52722 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuDJx-0000VS-Ot for ged-emacs-devel@m.gmane.org; Fri, 20 Dec 2013 22:33:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35655) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuDJo-0000VJ-3q for emacs-devel@gnu.org; Fri, 20 Dec 2013 22:33:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VuDJg-0001Pp-Pz for emacs-devel@gnu.org; Fri, 20 Dec 2013 22:33:36 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:37136) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VuDJg-0000sY-8Q for emacs-devel@gnu.org; Fri, 20 Dec 2013 22:33:28 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id 03DF7970902 for ; Sat, 21 Dec 2013 12:32:20 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id EA3F5136F25; Sat, 21 Dec 2013 12:32:19 +0900 (JST) In-Reply-To: <87mwjvfrfy.fsf@flea.lifelogs.com> X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.224 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:166680 Archived-At: Ted Zlatanov writes: > SM> - what completion operations take place: > SM> - insert a few chars at point > SM> - bring up a list of candidates > SM> - ... > > I think this should be unified as much as possible into a single > operation that takes place in any context, outside of the user's > control. IOW this should be the place where Emacs standardizes to only > one completion/selection API, possibly through the `completion-*' > functions. Please explain what you mean by "unify". If you mean one-size-fits-all, I think that would be horrible. There are completion contexts where I don't want a list at all (dabbrev), and others where I really, really do (browser completion of long URLs from long histories). If you simply mean there should be one function to invoke the completion system, or a small number of such functions, with a "small" number of parameters, I agree. I think this points out the need for a dispatching architecture, where the completion function exposed in the API ends up dispatching to several handlers: construct the candidate list, filter it, prioritize it, optionally present it to the user, and optionally edit the target text ("auto-complete" suggests that edit will always happen, but it's not always what is desired of a completion mechanism -- eg, something I've occasionally wished for is a "uniquifying completer", so that I don't accidentally duplicate identifiers -- "you can check out but you can never leave" until the item is unique in scope :-). > SM> - how to display the list of candidates: > SM> - in a separate buffer > SM> - at point, via clever overlay tricks > SM> - at point, via a special frame > SM> - at point, via a x-popup-menu > SM> - ... > > This should probably be customizable, but the default IMO should be > different between graphical and text mode, the way that `widget-choose' > does it. If you architect the system as dispatching handlers to perform certain tasks in sequence, you can postpone this decision (and, in fact, most of the decisions you are discussing here, prematurely IMHO). It seems to me that the custom "selectors" for instancing faces (or whatever the "keys" in a defface are called) would be a good choice for specifying completion "list display" handlers. Then you can start with "one size fits all" with a selector of t and easily generalize. The only nasty task in this architecture would be if it becomes necessary to split a handler into two. However, AFAICT from your immediate agreement to the agenda Stefan set here, the three of us (you, Stefan, me) agree 100% on what the options involved are, and I suspect we could also agree quite quickly on what tasks deserve separate handlers (some of the options probably need coordinated decisions to avoid screwing each other up, so should not be in separate handlers). That's only 3 people, but I think it's good evidence that agreement is going to be widespread, given how disparate our opinions have been on everything else in this thread. If somebody disagrees on the right setting for one of the options, they just write their own handler; no need for discussion (unless they want to propose it for default), and easy to experiment (as we've seen there are a wide range of opinions on how to do this, experimentation is an excellent idea). The hard part is going to be designing selectors for each handler. Some are going to be mostly dependent on display capability plus user preference (the list display), others may be purely application- dependent (selection of existing files is going to imply a list generated by `directory-files'), so the selectors aren't going to be one-size-fits-all. But to start with the only handler selection mechanism that needs to be implemented is t. :-) Additional selection criteria for a given handler can be added with only local surgery to the dispatcher. Steve