Re: Emacs completion matches selection UI

[Ted Zlatanov <tzz@lifelogs.com>]

On Mon, 18 Nov 2013 19:43:04 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> I've implemented a bridge between company-mode and
SM> completion-at-point-functions ("company-capf"), and moved company-mode's
SM> completion tables for Elisp into lisp-mode.el.  But there needs
SM> to be some further integration work to make sure company-mode works well
SM> with existing completion-at-point-functions.

SM> But it wouldn't be enabled by default, anyway.

The default match selection UI is not easy or intuitive, so that's one
problem.  I think it can be improved with better key bindings and better
formatting in the candidates buffer, but honestly any solution that pops
up a whole new buffer is unusable today in 2013.  Users are accustomed
to at least some kind of selection popup like what company-mode
provides.  Today's GUI toolkits on all our graphical platforms certainly
provide that functionality.

The second problem is that there are no alternatives to the default
match selection UI.  Your company-mode integration would help there.
Please let me know when it's ready for testing.

>> The completion system is fine.  The selection of matches is the problem:
>> 1) see a new buffer popup with minimal help text and no highlighting
>> 2) left, right, up, down don't work
>> 3) realize problem, switch to candidates buffer (mouse click or `C-x o')
>> 4) select candidate you want, get popped in original buffer
>> That's not simple!  It's not intuitive either, forcing me to use the
>> mouse unless I've read the manual node referenced above.
>> An alternative UI doesn't have to be fancy or graphical, only allow me
>> to select from among the candidates immediately, without switching
>> buffers, using the intuitive keys.  I hope that explains my request better.

SM> Oh, that should be reasonably easy.  Just add the corresponding
SM> key-bindings in minibuffer-local-completion-map, mostly.  The main issue
SM> is to try and avoid clashing with existing bindings (since there are
SM> 2 buffers at play: the minibuffer and the *Completions* buffer), and
SM> without C-x o, you're still in the minibuffer where left/right should
SM> still mean "cursor movement in the minibuffer".

I think these new keybindings should be the default for everyone so yes,
care is needed.  I don't know the right keys to use.

Remember you can also see the completion candidates buffer without the
minibuffer, if you e.g. do `complete-symbol' in a buffer.  So the
minibuffer is not the only context.

The most important thing IMO is to avoid making a new buffer that
requires `C-x o' and magical bindings.

On Tue, 19 Nov 2013 02:47:11 +0200 Juri Linkov <juri@jurta.org> wrote: 

JL> In modern UIs, auto-completion works such a way that after you type text
JL> it pops up a drop-down menu with a list of candidates where you can
JL> select one by using <down> and <up> arrow keys.

JL> How this could map to Emacs?  The first difference is that in Emacs
JL> the text entry field (the minibuffer) is at the bottom of the screen,
JL> so the drop-down menu should pop up upwards using the display-window
JL> property `near-minibuffer' (this will display completions nicely aligned
JL> with the contents of the minibuffer).

JL> Another difficulty is that in the minibuffer <up> and <down> arrow keys
JL> are bound to previous-history-element and next-history-element,
JL> so they can't be used to select an element from the list of candidates.

JL> One solution is to automatically display the list of completions
JL> when the user starts typing in the minibuffer and allow <up> and <down>
JL> to navigate the list of completions if the minibuffer contents is not empty.
JL> Otherwise, <up> and <down> will browse the history.

Note, as I mentioned above, that completion candidates can be presented
outside the minibuffer context as well.

JL> Since this is quite obtrusive change it might require special mode
JL> much like ido-mode but closer to auto-completion provided by other
JL> GUI applications.

I would argue that company-mode has solved the problem to some extent,
but I understand it's not a simple change.  I hope you and Stefan and
others have some idea of what needs to be done.  I'm happy to assist but
don't have the required knowledge of the internals to write code.

On Tue, 19 Nov 2013 11:18:09 +0000 (UTC) Tom <adatgyujto@gmail.com> wrote: 

T> [Helm] could also be considered as a possible alternative completion UI.

I use and love helm-mode, but it's not truly a completion UI, it's an
action selection UI.  It lacks context normally, meaning that I can call
`help-mini' any time in any buffer and it will be consistent.  That's
why I didn't propose it, even though it's very useful on its own.

The helm-mode code that narrows candidates and presents them in a nice
categorized buffer could certainly be considered together with
company-mode and the other completion UIs in existence.  I don't know if
it's usable in isolation from the rest of Helm.

Ted