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: Wed, 18 Dec 2013 10:58:44 +0900 Message-ID: <87d2kuzzqj.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87fvqtg02v.fsf@flea.lifelogs.com> <528B6F11.7070607@yandex.ru> <87y54ke8v3.fsf@flea.lifelogs.com> <87li0kdrsz.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1387332006 17564 80.91.229.3 (18 Dec 2013 02:00:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Dec 2013 02:00:06 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 18 03:00:12 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 1Vt6Qj-0005nb-Hg for ged-emacs-devel@m.gmane.org; Wed, 18 Dec 2013 03:00:09 +0100 Original-Received: from localhost ([::1]:36580 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vt6Qj-0003zQ-2H for ged-emacs-devel@m.gmane.org; Tue, 17 Dec 2013 21:00:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vt6Qb-0003ws-7h for emacs-devel@gnu.org; Tue, 17 Dec 2013 21:00:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vt6QT-0005BX-FV for emacs-devel@gnu.org; Tue, 17 Dec 2013 21:00:01 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:47647) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vt6QS-00057Y-U1 for emacs-devel@gnu.org; Tue, 17 Dec 2013 20:59:53 -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 B9579970A0A for ; Wed, 18 Dec 2013 10:58:44 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id AD5401A278B; Wed, 18 Dec 2013 10:58:44 +0900 (JST) In-Reply-To: <87eh5bkxca.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:166563 Archived-At: Ted Zlatanov writes: > On Tue, 17 Dec 2013 13:29:30 -0500 Stefan Monnier wrote: > SM> I'm not sure why you see it as something the user wouldn't like. > > Because it's not familiar. "Familiar" has never been a reason in itself for doing things in Emacs, and obviously "unfamiliar" is a superset of "innovative", so make sure you fish the baby out of the bathwater first. > In today's standard autocompleted lists, you finish the interaction > either down{n}+RET to select, ESC to cancel, or with input that > clears the candidate list (so none match). These are not special > commands. But they conflict with current Emacs interfaces (eg, ESC is sort of a prefix key). Why do you think it's worth doing that? (See below for why I don't think it's worth doing.) Oh, and don't bother answering if in Emacs you would substitute C-g for ESC (I don't feel that's a good idea either, but I can't justify that intuitive feeling). > The user is not captive to the UI. That's true in theory and in the long run, but in practice, in the short run, of course users are captive. UI gets into muscle memory. RMS says traditional Emacs key sequences are *more* efficient, but I don't agree. It turns out to be very hard to prove that a particular keyboard layout is overall more efficient UI (cf the many decades and still continuing Dvorak vs. QWERTY controversy), and I'm pretty sure the same is true of UI in general.[1] What clearly does matter is what you're used to, as anyone who must use multiple keyboards in the course of a day can testify. > Do you need examples of how popular and standard this behavior is > today? Ted, it's not about "popular" (especially not "popular with developers who create applications that make Emacs developers feel sick") and "standard". Until you get that, you're going to waste a lot of bytes. > Do they matter to you? Speaking for myself, "popular" and "standard" are idea sources, not reasons for adoption. In general, I'm very much in favor of standards. However, Emacs UI *is* different. You can't buy much with superficial familiarity if at some point Emacs is going to rip a hole in your reality. Using Emacs truly effectively is a continuous learning process. The unfamiliar UIs you talk about are less than 10% of the barrier to using Emacs. Of course you can use Emacs as a somewhat more powerful Notepad, but I don't think Emacs-with-*Office-keybindings would be particularly satisfying to folks who don't need more than that of a text editor. > SM> I think "list-selection" is a restrictive way to think about > SM> it: hitting TAB to complete doesn't necessarily mean "the user > SM> wants to select a completion candidate". It can also mean "the > SM> user wants to complete "fo" to "fooba" and then complete this > SM> identifier by adding something else that's not in any of the > SM> completion candidates. > > Right, so perhaps it can do all of that. But surely list selection > is a basic use case it should cover without trying to read minds? The standard widgets (Mozilla, Chrome, *Office, MS Office 2007) don't do "all of that". I find them only to be useful for recalling very recent history (which in Emacs would be one or two kill-ring rotate operations); otherwise I go to the more or less hierarchically organized, *fully modal* "bookmarks" or "history" mechanisms. *Office's inline completion behavior was the second thing I invoked help for.[2] Unable to figure out WTF[3], the third time I invoked help was to find out how to disable it. Since other people use those UIs happily enough, I can only conclude that they violate my idiosyncratic UI intuition, and (of course this is a guess, YMMV) I suspect they inherently conflict with Emacs-style completion mechanims. Footnotes: [1] OTOH, muscle strain and the like can be measured, and the injury implications of different keyboard form factors and shapes are well- established. [2] The first was to learn how to disable spelling and grammar auto-corruption. [3] OTOH, I quickly got used to iOS inline completion behavior, which offers *one* candidate. I have fat fingers, spelling corrections are usually correct here and I appreciate the help, especially at iPhone size.