Re: Emacs completion matches selection UI

[Ted Zlatanov]

On Sun, 22 Dec 2013 20:59:49 -0500 Stefan Monnier <address@hidden> wrote: 

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

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

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

OK, is there a way to make a verification and testing plan for this?  If
there was some automation around completion support, it would certainly
speed things up, but we need at least a list of currently non-compliant
modes in Emacs.  How do you look for the exceptions, by searching for
old functions or testing manually?

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

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

Using `up' in the minibuffer goes back in the history currently, which
invalidates the current completion candidates, so it does have some
effect.  But I agree it's not directly completion-related.

>> "Keep on editing" acts differently as well.

SM> Details?

Minor.

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

SM> If you add the qualifier "when the completion list is displayed",
SM> I think I agree, yes (I actually hesitated to add that feature when
SM> wrote the new minibuffer.el code, but then decided to keep it for later,
SM> sine there was plenty of other behavioral changes introduced at that
SM> time already).  You might want to make it configurable, but I think
SM> 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?

SM> Didn't I just agree in the previous paragraph?

OK.

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

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

So auto-narrowing (customizable) and a graphical popup (customizable as
a frontend choice) are OK.  Hijacking keys is to be tested further and a
demo is needed.  All this will happen with `completion-at-point'.

SM> The API design should presumably make it possible to use company-mode's
SM> overlay-based popups, or widget-choose's popup, or good ol'
SM> *Completions* buffer.

As with company-mode, this can be a frontend choice (affecting
`display-completion-list', and see below for the suggested
`display-list' function).  How about a defcustom
`completion-ui-frontend' with some choices?

SM> It should maybe also make it possible for the caller to provide some
SM> data that might influence which kind of popup to use (in case the
SM> kind of popup to use might depend on the context: not sure if that's
SM> really necessary), tho the ultimate choice should be with the user's
SM> config, of course.

For the user, a new defcustom `completion-ui-preferences'?  And for the
caller, some kind of plist/alist passed to `completion-at-point' that
merges cleanly with `completion-ui-preferences'?

s/completion-ui/something-else/ as you see fit.

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

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

I would like that, too, so choosing from a list of elements can use all
the improvements suggested here for `display-completion-list'.  Could
this be a new `display-list' function, used to display both completion
selection (through `display-completion-list') and list selection?

Ted