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: Thu, 19 Dec 2013 10:49:44 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87eh58j0x3.fsf@flea.lifelogs.com> References: <87fvqtg02v.fsf@flea.lifelogs.com> <87d2ltl2if.fsf@mail.jurta.org> <8338moevm3.fsf@gnu.org> <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> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1387468129 30808 80.91.229.3 (19 Dec 2013 15:48:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Dec 2013 15:48:49 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 19 16:48:56 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 1VtfqJ-0002kQ-Uk for ged-emacs-devel@m.gmane.org; Thu, 19 Dec 2013 16:48:56 +0100 Original-Received: from localhost ([::1]:44967 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtfqJ-0001Sz-IB for ged-emacs-devel@m.gmane.org; Thu, 19 Dec 2013 10:48:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55693) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtfqA-0001Hw-Oc for emacs-devel@gnu.org; Thu, 19 Dec 2013 10:48:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vtfq5-0003pG-RQ for emacs-devel@gnu.org; Thu, 19 Dec 2013 10:48:46 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:56632) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vtfq5-0003pC-F8 for emacs-devel@gnu.org; Thu, 19 Dec 2013 10:48:41 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Vtfq1-0002Qa-9e for emacs-devel@gnu.org; Thu, 19 Dec 2013 16:48:37 +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 ; Thu, 19 Dec 2013 16:48:37 +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 ; Thu, 19 Dec 2013 16:48:37 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 147 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:W21WP8R9w42KUo/fpT53EixDA0c= 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:166612 Archived-At: On Wed, 18 Dec 2013 22:40:39 -0500 Stefan Monnier wrote: >> If theres another point to this debate, please forgive me, because >> I have missed it. SM> Personally, I'm trying to understand what it is that Ted is suggesting. I've explained it so many times I'm starting to wonder if my English is the problem. I started with noticing the inconsistency and mish-mash code behind the completion candidate selection UI, then proposed a better UI for completion candidates, eventually recommending a standard API to select completion candidates (and list elements in general, if possible) and gave specific suggestions for how it should act and look. SM> Indeed, I do hope to bring something like company-mode into Emacs, maybe SM> even making it into the default in-buffer completion UI. SM> But the UI based on *Completions* is likely to stick around for a long SM> time, so it's important to integrate the two at some level. I see company-mode and others as hacks to get around the lack of a true completion popup. I really think `widget-choose' is the direction we should be going in graphical mode, and if *Completions* stays it should be only in text-mode. SM> For me the current "integration" is that they should all rely on SM> completion-at-point-functions, so that major modes can focus on SM> providing the best completion-at-point-function they can, so the SM> user can freely choose which UI they want to use. Exactly, that's not a problem. The data backend through `completion-at-point-function' works great. On Thu, 19 Dec 2013 00:45:47 -0500 chad wrote: c> To Stephens point, I think that theres a fairly large, demonstrated c> desire for some sort of wheel that looks and works a lot like (for c> example) auto-complete: c> http://www.emacswiki.org/emacs/AutoComplete c> We had a big discussion about this (same or very similar) topic c> several months ago when talking about Emacs as IDE, especially c> comparing Emacs and Eclipse. Im not %100 sure that this is what Ted c> is asking after, but I think so. Id also like to see such a wheel c> in Emacs, ideally built-in. The recent iswitchb/icomplete/ido c> discussion and conversations with several programmers (some current c> Emacs users, some ex-Emacs users) suggests to me that this is a big c> deal for potential Emacs users. Maybe its not desired or important c> for most established Emacs users; I dunno. Honestly, I think almost everyone has either hacked around it with the add-ons you mentioned or has trained themselves to ignore the bad UI. c> * Can we get a solid consensus on whether or not this sort of thing c> is desirable in Emacs? c> * If we think it’s a good idea to enable, should it be inside Emacs or c> in some external package? c> * If we think its a good idea to enable, what do we need in order to c> make it compatible with Emacs internal directions and reusable for c> multiple packages? Same questions here, and Stefan answered them to some degree, but perhaps he should make a clear statement setting the direction after the upcoming release. I'm happy to work on improving the user experience, but don't want to find out after spending a weekend on the code that I've misunderstood where we're going. See below as well. On Thu, 19 Dec 2013 15:23:54 +0900 "Stephen J. Turnbull" wrote: >> Here's a fairly standard autocomplete widget in today's Web, SJT> Would you please stop assuming that people who disagree with you are SJT> cavemen hunkered down over their teletypes with paper tape attachments, SJT> ADM-3s and (wow, shiny!) Hazeltine 1510s who dream of buying a VT-220 SJT> like the one Mr. Sulu uses on Star Trek? Perhaps you can look at the URL and explore all the options and use cases offered by the jQuery UI autocomplete widget instead of assuming my goal is to traumatize you with shiny things. The jQuery UI library didn't become a de facto standard by accident, it really is a good API. SJT> I know what such widgets look like, thank you, but I mostly ignore SJT> them [...] You can argue that that's because I'm familiar with SJT> Emacs completion and use Emacs in the majority of my workflows. Yes. Most of us are terrible at detecting bad UI in the tools we use every day, and pretending otherwise is disingenuous. SJT> But that brings us back to the question of "why should we adopt a SJT> goal of familiarity to *non*-Emacs-users?" I don't see a good SJT> reason *adapt Emacs to them*; I think it's preferable to help new SJT> users to *adapt workflows to Emacs*. Understood, thank you for your opinion. >> But more importantly, I don't want to see a special text buffer in >> graphical mode. SJT> Maybe it's just me, but I can't interpret that, let alone agree with SJT> it. Do you mean you don't want the *Completions* buffer to be a SJT> presented in an Emacs window with the usual decorations (modeline, SJT> scrollbars, and whatnot)? That I can agree with. Yes. I think that looks and feels awkward, and the selection of candidates is particularly awkward. SJT> I imagine the basic underlying data structure being the usual SJT> *Completions*[1] buffer, with three different presentations: (1) a SJT> standard 2-D presentation of *Completions* in a multiline minibuffer SJT> window (to reduce the decorations to a minimum), with the current SJT> input at the bottom in a different face, (2) a (translucent) popup SJT> overlay containing a 2-D presentation of the same buffer in GUI SJT> (perhaps with different row x column dimensions), and (3) (not really SJT> relevant to today's Emacsen, but just for creativity's sake) a popup SJT> size-weighted "tag cloud"-style presentation with "higher-priority" SJT> completions both larger and nearer the center SJT> I haven't thought much about the selection interface (keymaps), but I SJT> suppose for all three a click (or tap) would select, and for the first SJT> two 2-D "arrow" navigation would be appropriate (if the items are SJT> small enough), suggesting ordering the items by "Manhattan distance" SJT> and warping the cursor to somewhere in the middle of the "completions SJT> window", while for the tag cloud the arrow keys would move backward SJT> and forward through a linear order. N.B. For a 2-D display that SJT> degenerates into a single column because of wide individual items, the SJT> keymap would automatically reduce to forward = down and backward = up. I think you've described (except for the tag cloud, which IMO is a horrible user experience) more or less what I would like to see as well, with some additions: * hidden behind a standard built-in API call * supporting plugins for look, feel, behavior * the user can choose how the UI should look and behave in general * works the same way in minibuffer and in-region invocations * default look and keybindings are close to familiar/standard/etc. today (ideally using the native platform's widgets, which would DTRT depending on many things Emacs just doesn't know or control) Thanks! Ted