Re: Emacs completion matches selection UI

[Stefan Monnier]

> I mean TAB (and its equivalent in-buffer keybinding) should be bound to
> a single Elisp function, and the effect (list candidates, complete
> immediately the single candidate, or cycle candidates depending on the
> user preferences) should be consistent in any invocation context.

Not sure what you feel is missing here.  `completion-at-point' is
basically it, AFAICT.  But it's OK if different UIs provide other
commands (or other ways, since completion can also happen as
a side-effect of normal commands, as is the case with auto-complete and
company-mode).

The important point is that the completion command to use shouldn't
depend on the "backend" (e.g. on the current major mode), and AFAIK
we're almost there (the new completion code in Emacs-23 and subsequent
bit-by-bit updates of major modes to make use of
completion-at-point-functions was dedicated to this task).
Can't remember what are the remaining exceptions, other than Eshell.

SM> Hmm... Could you explain which parts are not consistent?
> "Select with up/down" is not consistent between in-minibuffer and
> in-buffer completion.

AFAIK it is consistent: neither in minibuffer nor in in-buffer up/down
is bound to a completion-related command.  It's not what you want, but
it's consistent w.r.t the completion UI.

> You can always go into the *Completions* buffer and then use up/down,
> but up/down immediately have different effects otherwise.

Lots of other keys have different effects in minibuffers and normal
buffers, but these don't make the completion code inconsistent in
this respect.

> I think they should do the same thing, enter a special popup
> as Dmitry and I described.

If/when those keys are given a completion-related meaning I'd expect it
to be the same in both contexts, yes.

> "Keep on editing" acts differently as well.

Details?

> OK, so do we agree on this specific improvement?  "Whether in the
> minibuffer or in a buffer, typing more characters should narrow the list
> of candidates without having to press TAB or other special keys."

If you add the qualifier "when the completion list is displayed",
I think I agree, yes (I actually hesitated to add that feature when
wrote the new minibuffer.el code, but then decided to keep it for later,
sine there was plenty of other behavioral changes introduced at that
time already).  You might want to make it configurable, but I think
enabling it by default would be OK.

SM> Usually, if it works for in-buffer, it works as well in the
SM> minibuffer case.
> Good point.  But why not simply enter an auto-narrowing popup in both
> contexts?

Didn't I just agree in the previous paragraph?

> The user has explicitly requested completion, right?  I keep
> thinking that if in both contexts we locked the user into a selection
> popup, the up/down and motion issues would be easily solved.  It would
> also allow `C-1' through `C-9' (or some similar keys) to be used to
> immediately select a candidate by position, like `widget-choose' does it.

As I already said in earlier discussions, it might very well be
acceptable to hijack those keys.  But only experience can confirm it.

SM> I still don't quite understand what you want here.  Are you thinking of
SM> a function like x-popup-menu or display-completion-list?
> Yes, `display-completion-list' but hacked to use `widget-choose' at
> least in graphical mode and to auto-narrow.

Here again you're confusing API and implementation.  Be very careful,
please, because it's making this discussion difficult.

The API design should presumably make it possible to use company-mode's
overlay-based popups, or widget-choose's popup, or good ol'
*Completions* buffer.  It should maybe also make it possible for the
caller to provide some data that might influence which kind of popup to
use (in case the kind of popup to use might depend on the context: not
sure if that's really necessary), tho the ultimate choice should be with
the user's config, of course.

> This should work with (interactive) calls, of course, as a common
> use case.

I'm again lost here.  We're talking about a *function* which needs to be
told *by another Lisp function* what it is that needs to be displayed.
So it's meaningless to consider interactive calls.

> So let's say I'm inside gnutls.el and want to ask the user to select a
> client certificate to present to the remote server.  I have a list of 3
> such certificates.  I would say `(display-completion-list
> list-of-certificates)' and expect the result to be nil or an element of
> the list.  Does that usage make sense?

No.  That would seem to call for a completely different API meant to
generalize completing-read rather than display-completion-list.


        Stefan