Re: Emacs completion matches selection UI

["Stephen J. Turnbull" <stephen@xemacs.org>]

Ted Zlatanov writes:
 > On Tue, 17 Dec 2013 13:29:30 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> 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.