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: Fri, 20 Dec 2013 12:06:42 +0900 Message-ID: <8761qkp6f1.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87fvqtg02v.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> <878uvg4ul2.fsf@yandex.ru> <87y53ghe94.fsf@flea.lifelogs.com> <87vbyk3497.fsf@yandex.ru> <87haa4gw69.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 1387508819 2078 80.91.229.3 (20 Dec 2013 03:06:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 20 Dec 2013 03:06:59 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 20 04:07:05 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 1VtqQa-00033p-8J for ged-emacs-devel@m.gmane.org; Fri, 20 Dec 2013 04:07:04 +0100 Original-Received: from localhost ([::1]:47544 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtqQZ-0007Nr-Pm for ged-emacs-devel@m.gmane.org; Thu, 19 Dec 2013 22:07:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtqQQ-0007Nf-IZ for emacs-devel@gnu.org; Thu, 19 Dec 2013 22:07:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VtqQH-0000lK-N7 for emacs-devel@gnu.org; Thu, 19 Dec 2013 22:06:54 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:51985) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtqQH-0000fj-70 for emacs-devel@gnu.org; Thu, 19 Dec 2013 22:06:45 -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 60F229708DB for ; Fri, 20 Dec 2013 12:06:42 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5528A136F25; Fri, 20 Dec 2013 12:06:42 +0900 (JST) In-Reply-To: <87haa4gw69.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:166645 Archived-At: Ted Zlatanov writes: > I don't think I ever said it should be different from all existing, > just that it should be a standard API we can all use and customize Stefan has said this is a good idea. Repeatedly. > I'm happy to have it look and behave more or less like > `widget-choose' as I said several times, or like a native widget. And now you're wandering off into specifyinging behavior again, within four lines of the same paragraph. This is one important reason why people are having trouble understanding just what you are proposing. What I understand Stefan to want Now is a *single* API that can be called for both at-point and in-minibuffer completion. As I understand it, he wants the first step to involve *decoupling* the user-visible behavior from the completion API that the "rest of Emacs" sees, allowing an array of *different* UIs (== "backend" behaviors) to be attached to the *same* API ("frontend"). He seems to expect that the *behavior* implemented initially will be based on (one of) the existing at-point mechanisms available in core. *I* believe that will make the contrast between old and new APIs for developers of applications that use completion more clear, and *perhaps* that is Stefan's rationale as well. If such developers prefer different behavior to the one (or few) initially implemented, the first test of the value of the new API will be the ease with which they can install such new behaviors. The second test, of course, will be the ease with which non-developer users can customize the UI (here I mean "swap in different backends", not "GUI theming"). P.S. Note that I probably am using "frontend" and "backend" in a sense reversed to what many people expect. It's the same kind of thing as the "client-server" reversal in the X Window System. I'm taking that point of view of the developer who is facing the completion API, and therefore call the API "front". After passing through the completion implementation, he reaches the user-facing "back".