Re: Emacs completion matches selection UI

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 19 Nov 2013 12:50:38 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> The main issue is then to figure out how/when to switch to this
SM> new mode.  E.g. when the user hits `up' right after the *Completions*
SM> buffer got displayed/updated?
>> Maybe the trigger should be another `TAB'?  That's what I would press,
>> intuitively.

SM> Another TAB currently means "scroll the *Completions* buffer".
SM> I'm not sure if we want to get rid of that feature.
...
SM> (tho I think the way this new mode should work, it should not
SM> switch to the *Completions* window, but instead just change key-bindings
SM> in the minibuffer to highlight/select an entry in *Completions*).

Agreed, although then the *Completions* buffer should at least get
better highlighting.

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

SM> There's nothing special there: just the company-capf in the latest
SM> company package.

OK, thanks.

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

SM> I think you mean `completion-at-point'.  Indeed, that is a lot more
SM> tricky, since in such a context, keys can have any number of
SM> other bindings, and it's quite normal to hit `up' or `down' with the
SM> intention of "move to the other line because I'm done writing this
SM> completable element", so hijacking `up' or `down' in this context is
SM> more delicate.

I agree, and my proposal is to "lock in" the user into the selection
mode until it's done.  If we do that, it becomes OK to hijack primary
motion commands until the selection is made.  In effect the buffer
should be unavailable during the selection.

SM> But I'm not completely sure whether the minibuffer completion UI has to be
SM> identical to the in-buffer completion UI.  Of course, it's good for them
SM> to be identical, all things being equal, but: things like company-mode don't
SM> work well in the minibuffer, whereas the separate *Completions* buffer
SM> actually works OK in that case (whereas it's much more problematic for
SM> in-buffer completion where the *Completions* buffer may be fairly far
SM> from point).

I understand.  I think an abstract popup facility would work in either
case, especially if it "locks in" the user as described above.  But if
something must be improved, it's the in-buffer completion UI IMO.

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

SM> My suggestion is to keep the separate buffer but let the user interact
SM> with it without needing to switch to it via C-x o or some such action.

SM> That seems doable without too much trouble in the current setup.  If we
SM> want to avoid the separate buffer altogether, then we're in
SM> auto-complete/company-mode territory, which won't happen for 24.4.

OK, let's pursue that path for 24.4 and then see if a more radical
library or API can be used later.

I see the following 24.4 tasks so far:

- improve *Completions* buffer highlighting

- decide on "locking in" users during candidate selection (so more
  natural keybindings can be used) or stealing just a few keybindings
  temporarily

- improve minibuffer candidate selection UI keys (depends on "lock in" decision)

- improve in-buffer candidate selection UI keys (depends on "lock in" decision)

Does that sound reasonable?

Ted