Re: Emacs completion matches selection UI

[Ted Zlatanov]

On Wed, 18 Dec 2013 13:47:40 +0900 "Stephen J. Turnbull" <address@hidden> 
wrote: 

SJT> Oh, in *that* sense, yes -- but that's cheating.  *Your* argument
SJT> requires the meaning "familiar to people who aren't familiar with
SJT> Emacs", and I adopted your terminology.

I am trying to explain that people like what's familiar to them and call
it "intuitive" and "easy to use."  The vast majority of applications in
existence have adopted some conventions for how to select items from a
list, so "users" in general are familiar with those conventions.

Emacs users and developers have developed their own UI conventions, many
predating modern user interfaces (both the conventions and the
users/developers!).  So any time you try to discuss improvements to the
Emacs UI, you have two versions of "familiar" and each side in the
debate is very attached to their version of it and somewhat blind to the
other side's version.  The best way forward seems to be to look at
specific solutions of the problem outside Emacs, preferably without
mentioning Apple or Microsoft products because they tend to polarize the
debate quickly.

Please also understand I am not talking about actual functionality here,
only about the user experience.  Emacs is by far more powerful and
useful than most products on the market, but without a good user
experience it's harder to discover that.

SJT> HCI research is mostly crap, AFAICT.

OK, I guess that settles it.

>> 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.

SJT> At that point Emacs and the rest of the world (including shells) part
SJT> company, and I don't see anything in your argument that deals with
SJT> that discontinuity.

I understand the concern, and think that the following suggestions are
not badly discontinuous for simple list selection, a very common use
case:

* selection candidates should be displayed near the point where the user
  requested the list.  In a buffer, this is (point).  In the minibuffer,
  this is the input position.

* 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)

* up/down should move between candidates until selection

* any other self-insert character should narrow the selection further
  and get inserted in the original context

* RET should complete the selection

* ESC or C-g should cancel the selection

* further TABs could have special effects, e.g. select current candidate
  and move on to next selection step (Stefan's example of doing more
  than basic list selection).  I don't feel strongly about this one,
  personally.

SJT> Feel free to expand on the libreadline example, though.  I suspect it
SJT> falls apart in the sense that I know that I want *consistent*
SJT> completion throughout Emacs, where a minibuffer is just a buffer that
SJT> happens to be one line high.  Whereas libreadline is highly optimized
SJT> to work with the constraint that the buffer *is* exactly one line
SJT> high.  But that's mostly uninformed intuition, somewhat informed by
SJT> the idea of a "reality discontinuity".

I was trying to give you examples of other solutions to the same problem
that are closer to the Emacs users' and developers' expectations,
because I feel talking about GUIs inevitably gets into the wrong kind of
arguments about Office and so on (none of which interests me, as I
mentioned above I only want to discuss the user experience, not the
functionality).  libreadline is very familiar to our group and is a good
API example to study, but it has significant limitations as you know.

zsh completion is another great example, where you have highly
context-sensitive modules to complete command options and values,
written in a fairly primitive language.  The user can choose to enable
or disable completion modules and change completion options.  zsh
completion supports multiline display of candidates and in many ways
behaves like the in-buffer completion Emacs does today, including
dismiss-on-input behavior.

Ted