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 13:47:40 +0900 Message-ID: <878uvizrwz.fsf@uwakimon.sk.tsukuba.ac.jp> References: <87fvqtg02v.fsf@flea.lifelogs.com> <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> <87d2kuzzqj.fsf@uwakimon.sk.tsukuba.ac.jp> <87a9fylusq.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 1387342137 10507 80.91.229.3 (18 Dec 2013 04:48:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Dec 2013 04:48:57 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 18 05:49:01 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 1Vt949-0004pq-He for ged-emacs-devel@m.gmane.org; Wed, 18 Dec 2013 05:49:01 +0100 Original-Received: from localhost ([::1]:36937 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vt949-0000Vu-7A for ged-emacs-devel@m.gmane.org; Tue, 17 Dec 2013 23:49:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58926) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vt942-0000Uw-5c for emacs-devel@gnu.org; Tue, 17 Dec 2013 23:48:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vt93x-0007oZ-5N for emacs-devel@gnu.org; Tue, 17 Dec 2013 23:48:54 -0500 Original-Received: from mgmt2.sk.tsukuba.ac.jp ([130.158.97.224]:50500) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vt93w-0007Yn-K8 for emacs-devel@gnu.org; Tue, 17 Dec 2013 23:48:49 -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 9B7D0970905 for ; Wed, 18 Dec 2013 13:47:40 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 8DC3211F85A; Wed, 18 Dec 2013 13:47:40 +0900 (JST) In-Reply-To: <87a9fylusq.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:166568 Archived-At: Ted Zlatanov writes: > On Wed, 18 Dec 2013 10:58:44 +0900 "Stephen J. Turnbull" wrote: > > SJT> 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. > > SJT> "Familiar" has never been a reason in itself for doing things in > SJT> Emacs > > Sure it has. Oh, in *that* sense, yes -- but that's cheating. *Your* argument requires the meaning "familiar to people who aren't familiar with Emacs", and I adopted your terminology. > SJT> and obviously "unfamiliar" is a superset of "innovative", so make > SJT> sure you fish the baby out of the bathwater first. > > I think the "baby" is decades of HCI research we seem to ignore. HCI research is mostly crap, AFAICT. (The part that worked on Dvorak vs. QWERTY has been thoroughly documented to be mostly crap.) For example, I don't really see any productivity differences among C-c/C-x/C-v, M-w/C-w/C-y, and whatever it is that vi uses. What's important about CUA and Emacs is that they're *everywhere* in the user's "app space". No surprise there, and Emacs already has that, since before CUA took over the world, too. That's precisely why Emacs users tend to "live" in Emacs: it provides a highly optimized UI that they are familiar with, used to, and know how to extend. Discoverability does matter, I admit. Apple seems to have gotten that right, but are we really going to revise all of Emacs to be compatible with a one-button mouse? > >> Do you need examples of how popular and standard this behavior is > >> today? > > SJT> Ted, it's not about "popular" (especially not "popular with developers > SJT> who create applications that make Emacs developers feel sick") and > SJT> "standard". > > Hey, I think you need an example! libreadline (and most shells that use > it). Attacking the Notepad/W32/crapGUI straw man won't help this > discussion. I wasn't talking about Notepad or the Win32 API at that point. I was talking about the fact that *Office isn't what Richard or I or the org-mode devs :-) want in a word processor. And it's not the sucky GUI that I was talking about when I mentioned Notepad. It's the reality discontinuity that occurs when you want to do something more than libreadline or Notepad can do (except for the height of the "text widget", they're arguably of similar power :-). At that point Emacs and the rest of the world (including shells) part company, and I don't see anything in your argument that deals with that discontinuity. Feel free to expand on the libreadline example, though. I suspect it falls apart in the sense that I know that I want *consistent* completion throughout Emacs, where a minibuffer is just a buffer that happens to be one line high. Whereas libreadline is highly optimized to work with the constraint that the buffer *is* exactly one line high. But that's mostly uninformed intuition, somewhat informed by the idea of a "reality discontinuity".