[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs completion matches selection UI

From: Stephen J. Turnbull
Subject: Re: Emacs completion matches selection UI
Date: Wed, 18 Dec 2013 13:47:40 +0900

Ted Zlatanov writes:
 > On Wed, 18 Dec 2013 10:58:44 +0900 "Stephen J. Turnbull" <address@hidden> 
 > wrote: 
 > SJT> Ted Zlatanov writes:
 > >> On Tue, 17 Dec 2013 13:29:30 -0500 Stefan Monnier <address@hidden> 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".

reply via email to

[Prev in Thread] Current Thread [Next in Thread]