Re: Emacs completion matches selection UI

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > I thought I explained it pretty clearly in this thread so I won't recap
 > it.  The topic is the current UI for selecting completion candidates
 > (and items from a list in general).  The question is whether it can be
 > improved;

No, it's not.  "Anything can be improved" is a general principle and
one of the fundamental raison d'etres of free software.  Stop pointing
to strawmen and maybe we can get somewhere.

 > we have proposed some specific improvements and at least having
 > "down/up" go into the "select candidates" mode was reasonably well
 > received.

"Modes" in the sense you are talking about here are an antipattern in
Emacs.

 > SJT> How can you avoid mentioning the two most "familiar" UIs in the
 > SJT> business (backed up by a pile of HCI research)?
 > 
 > Watch me :)  I managed to give two relevant examples (libreadline and
 > zsh).  I can give more: Qt, GTK, Motif...

Five patterns I'd rather not see Emacs emulate (though for different
reasons in the case of the shell libraries and in the case of the
GUIs).  IMO none of them are as good as Windows, let alone Mac OS/iOS
and Android, and the GUIs are obviously inferior emulations.  Was that
your point? ;-)

 > Here's a fairly standard autocomplete widget in today's Web,

Would you please stop assuming that people who disagree with you are
cavemen hunkered down over their teletypes with paper tape attachments,
ADM-3s and (wow, shiny!) Hazeltine 1510s who dream of buying a VT-220
like the one Mr. Sulu uses on Star Trek?

I know what such widgets look like, thank you, but I mostly ignore
them because their advice is way below the threshold of utility in 90%
of my workflows.  Ie, it's faster to type until the desired candidate
is at the top of the list, then select it -- very like the way Emacs
completion currently works, but suboptimal because of the extra
keystrokes.  The alternative of shifting gears, engaging the popup,
and select from a list is much slower in most cases, and in the
majority of cases where "keep typing" is inferior to selection from a
menu, minibuffer-style history rotation is faster than both.

You can argue that that's because I'm familiar with Emacs completion
and use Emacs in the majority of my workflows.  No doubt that's most
of the reason.  But that brings us back to the question of "why should
we adopt a goal of familiarity to *non*-Emacs-users?"  I don't see a
good reason *adapt Emacs to them*; I think it's preferable to help new
users to *adapt workflows to Emacs*.

 > >> * 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)
 > 
 > SJT> Huh?  *Completions* is a special text buffer, no?
 > 
 > Not in the same way if I understand the code in minibuffer.el
 > correctly.

Why are you referring to implementation technique here?  I thought you
were interested in look-and-feel?

 > But more importantly, I don't want to see a special text buffer in
 > graphical mode.

Maybe it's just me, but I can't interpret that, let alone agree with
it.  Do you mean you don't want the *Completions* buffer to be a
presented in an Emacs window with the usual decorations (modeline,
scrollbars, and whatnot)?  That I can agree with.

I imagine the basic underlying data structure being the usual
*Completions*[1] buffer, with three different presentations: (1) a
standard 2-D presentation of *Completions* in a multiline minibuffer
window (to reduce the decorations to a minimum), with the current
input at the bottom in a different face, (2) a (translucent) popup
overlay containing a 2-D presentation of the same buffer in GUI
(perhaps with different row x column dimensions), and (3) (not really
relevant to today's Emacsen, but just for creativity's sake) a popup
size-weighted "tag cloud"-style presentation with "higher-priority"
completions both larger and nearer the center (for touch-activated
devices, especially those with small form factors).  With "wide"
items, you could imagine the "current selection" "blowing up" as the
user scrolls through a 1-D list.

I haven't thought much about the selection interface (keymaps), but I
suppose for all three a click (or tap) would select, and for the first
two 2-D "arrow" navigation would be appropriate (if the items are
small enough), suggesting ordering the items by "Manhattan distance"
and warping the cursor to somewhere in the middle of the "completions
window", while for the tag cloud the arrow keys would move backward
and forward through a linear order.  N.B. For a 2-D display that
degenerates into a single column because of wide individual items, the
keymap would automatically reduce to forward = down and backward = up.


Footnotes: 
[1]  For the "tag cloud" presentation it might need to be a more
sophisticated data structure, since each item could have a cardinal
weight, not just an ordinal position.