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: Thu, 19 Dec 2013 15:23:54 +0900 Message-ID: <87vbylxssl.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87fvqtg02v.fsf@flea.lifelogs.com> <878uwi8t3r.fsf@mail.jurta.org> <83ob5ee7ow.fsf@gnu.org> <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1387434383 28723 80.91.229.3 (19 Dec 2013 06:26:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Dec 2013 06:26:23 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 19 07:26:29 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 1VtX40-0007u8-NE for ged-emacs-devel@m.gmane.org; Thu, 19 Dec 2013 07:26:28 +0100 Original-Received: from localhost ([::1]:42399 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtX3z-0000fh-Vp for ged-emacs-devel@m.gmane.org; Thu, 19 Dec 2013 01:26:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtX3B-0007yi-QB for emacs-devel@gnu.org; Thu, 19 Dec 2013 01:25:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VtX2c-0000gh-Ir for emacs-devel@gnu.org; Thu, 19 Dec 2013 01:25:37 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:39698) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VtX2c-0000Hz-1Y for emacs-devel@gnu.org; Thu, 19 Dec 2013 01:25:02 -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 70C509708E0 for ; Thu, 19 Dec 2013 15:23:54 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 5CC1E11F85A; Thu, 19 Dec 2013 15:23:54 +0900 (JST) In-Reply-To: <87k3f2j7xv.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:166606 Archived-At: Ted Zlatanov writes: > I thought I explained it pretty clearly in this thread so I won't recap > it. The topic is the current UI for selecting completion candidates > (and items from a list in general). The question is whether it can be > improved; No, it's not. "Anything can be improved" is a general principle and one of the fundamental raison d'etres of free software. Stop pointing to strawmen and maybe we can get somewhere. > we have proposed some specific improvements and at least having > "down/up" go into the "select candidates" mode was reasonably well > received. "Modes" in the sense you are talking about here are an antipattern in Emacs. > SJT> How can you avoid mentioning the two most "familiar" UIs in the > SJT> business (backed up by a pile of HCI research)? > > Watch me :) I managed to give two relevant examples (libreadline and > zsh). I can give more: Qt, GTK, Motif... Five patterns I'd rather not see Emacs emulate (though for different reasons in the case of the shell libraries and in the case of the GUIs). IMO none of them are as good as Windows, let alone Mac OS/iOS and Android, and the GUIs are obviously inferior emulations. Was that your point? ;-) > Here's a fairly standard autocomplete widget in today's Web, Would you please stop assuming that people who disagree with you are cavemen hunkered down over their teletypes with paper tape attachments, ADM-3s and (wow, shiny!) Hazeltine 1510s who dream of buying a VT-220 like the one Mr. Sulu uses on Star Trek? I know what such widgets look like, thank you, but I mostly ignore them because their advice is way below the threshold of utility in 90% of my workflows. Ie, it's faster to type until the desired candidate is at the top of the list, then select it -- very like the way Emacs completion currently works, but suboptimal because of the extra keystrokes. The alternative of shifting gears, engaging the popup, and select from a list is much slower in most cases, and in the majority of cases where "keep typing" is inferior to selection from a menu, minibuffer-style history rotation is faster than both. You can argue that that's because I'm familiar with Emacs completion and use Emacs in the majority of my workflows. No doubt that's most of the reason. But that brings us back to the question of "why should we adopt a goal of familiarity to *non*-Emacs-users?" I don't see a good reason *adapt Emacs to them*; I think it's preferable to help new users to *adapt workflows to Emacs*. > >> * they should be displayed without a dedicated *Completions* > >> buffer, like `widget-choose' does it (special text buffer in > >> text mode, nice popup in graphical mode) > > SJT> Huh? *Completions* is a special text buffer, no? > > Not in the same way if I understand the code in minibuffer.el > correctly. Why are you referring to implementation technique here? I thought you were interested in look-and-feel? > But more importantly, I don't want to see a special text buffer in > graphical mode. Maybe it's just me, but I can't interpret that, let alone agree with it. Do you mean you don't want the *Completions* buffer to be a presented in an Emacs window with the usual decorations (modeline, scrollbars, and whatnot)? That I can agree with. I imagine the basic underlying data structure being the usual *Completions*[1] buffer, with three different presentations: (1) a standard 2-D presentation of *Completions* in a multiline minibuffer window (to reduce the decorations to a minimum), with the current input at the bottom in a different face, (2) a (translucent) popup overlay containing a 2-D presentation of the same buffer in GUI (perhaps with different row x column dimensions), and (3) (not really relevant to today's Emacsen, but just for creativity's sake) a popup size-weighted "tag cloud"-style presentation with "higher-priority" completions both larger and nearer the center (for touch-activated devices, especially those with small form factors). With "wide" items, you could imagine the "current selection" "blowing up" as the user scrolls through a 1-D list. I haven't thought much about the selection interface (keymaps), but I suppose for all three a click (or tap) would select, and for the first two 2-D "arrow" navigation would be appropriate (if the items are small enough), suggesting ordering the items by "Manhattan distance" and warping the cursor to somewhere in the middle of the "completions window", while for the tag cloud the arrow keys would move backward and forward through a linear order. N.B. For a 2-D display that degenerates into a single column because of wide individual items, the keymap would automatically reduce to forward = down and backward = up. Footnotes: [1] For the "tag cloud" presentation it might need to be a more sophisticated data structure, since each item could have a cardinal weight, not just an ordinal position.