Re: Emacs completion matches selection UI

[Ted Zlatanov <tzz@lifelogs.com>]

On Wed, 18 Dec 2013 22:40:39 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

>> If theres another point to this debate, please forgive me, because
>> I have missed it.

SM> Personally, I'm trying to understand what it is that Ted is suggesting.

I've explained it so many times I'm starting to wonder if my English is
the problem.  I started with noticing the inconsistency and mish-mash
code behind the completion candidate selection UI, then proposed a
better UI for completion candidates, eventually recommending a standard
API to select completion candidates (and list elements in general, if
possible) and gave specific suggestions for how it should act and look.

SM> Indeed, I do hope to bring something like company-mode into Emacs, maybe
SM> even making it into the default in-buffer completion UI.
SM> But the UI based on *Completions* is likely to stick around for a long
SM> time, so it's important to integrate the two at some level.

I see company-mode and others as hacks to get around the lack of a true
completion popup.  I really think `widget-choose' is the direction we
should be going in graphical mode, and if *Completions* stays it should
be only in text-mode.

SM> For me the current "integration" is that they should all rely on
SM> completion-at-point-functions, so that major modes can focus on
SM> providing the best completion-at-point-function they can, so the
SM> user can freely choose which UI they want to use.

Exactly, that's not a problem.  The data backend through
`completion-at-point-function' works great.

On Thu, 19 Dec 2013 00:45:47 -0500 chad <yandros@gmail.com> wrote: 

c> To Stephens point, I think that theres a fairly large, demonstrated
c> desire for some sort of wheel that looks and works a lot like (for
c> example) auto-complete:

c> 	http://www.emacswiki.org/emacs/AutoComplete

c> We had a big discussion about this (same or very similar) topic
c> several months ago when talking about Emacs as IDE, especially
c> comparing Emacs and Eclipse. Im not %100 sure that this is what Ted
c> is asking after, but I think so. Id also like to see such a wheel
c> in Emacs, ideally built-in. The recent iswitchb/icomplete/ido
c> discussion and conversations with several programmers (some current
c> Emacs users, some ex-Emacs users) suggests to me that this is a big
c> deal for potential Emacs users. Maybe its not desired or important
c> for most established Emacs users; I dunno.

Honestly, I think almost everyone has either hacked around it with the
add-ons you mentioned or has trained themselves to ignore the bad UI.

c> * Can we get a solid consensus on whether or not this sort of thing
c>   is desirable in Emacs?

c> * If we think it’s a good idea to enable, should it be inside Emacs or
c>   in some external package?

c> * If we think its a good idea to enable, what do we need in order to
c>   make it compatible with Emacs internal directions and reusable for
c>   multiple packages? 

Same questions here, and Stefan answered them to some degree, but
perhaps he should make a clear statement setting the direction after the
upcoming release.  I'm happy to work on improving the user experience,
but don't want to find out after spending a weekend on the code that
I've misunderstood where we're going.  See below as well.

On Thu, 19 Dec 2013 15:23:54 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

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

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

Perhaps you can look at the URL and explore all the options and use
cases offered by the jQuery UI autocomplete widget instead of assuming
my goal is to traumatize you with shiny things.  The jQuery UI library
didn't become a de facto standard by accident, it really is a good API.

SJT> I know what such widgets look like, thank you, but I mostly ignore
SJT> them [...] You can argue that that's because I'm familiar with
SJT> Emacs completion and use Emacs in the majority of my workflows.

Yes.  Most of us are terrible at detecting bad UI in the tools we use
every day, and pretending otherwise is disingenuous.

SJT> But that brings us back to the question of "why should we adopt a
SJT> goal of familiarity to *non*-Emacs-users?"  I don't see a good
SJT> reason *adapt Emacs to them*; I think it's preferable to help new
SJT> users to *adapt workflows to Emacs*.

Understood, thank you for your opinion.

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

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

Yes.  I think that looks and feels awkward, and the selection of
candidates is particularly awkward.

SJT> I imagine the basic underlying data structure being the usual
SJT> *Completions*[1] buffer, with three different presentations: (1) a
SJT> standard 2-D presentation of *Completions* in a multiline minibuffer
SJT> window (to reduce the decorations to a minimum), with the current
SJT> input at the bottom in a different face, (2) a (translucent) popup
SJT> overlay containing a 2-D presentation of the same buffer in GUI
SJT> (perhaps with different row x column dimensions), and (3) (not really
SJT> relevant to today's Emacsen, but just for creativity's sake) a popup
SJT> size-weighted "tag cloud"-style presentation with "higher-priority"
SJT> completions both larger and nearer the center

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

I think you've described (except for the tag cloud, which IMO is a
horrible user experience) more or less what I would like to see as well,
with some additions:

* hidden behind a standard built-in API call

* supporting plugins for look, feel, behavior

* the user can choose how the UI should look and behave in general

* works the same way in minibuffer and in-region invocations

* default look and keybindings are close to familiar/standard/etc. today
  (ideally using the native platform's widgets, which would DTRT
   depending on many things Emacs just doesn't know or control)

Thanks!
Ted