Re: Emacs completion matches selection UI

[Ted Zlatanov]

On Sat, 21 Dec 2013 21:05:24 -0500 Stefan Monnier <address@hidden> wrote: 

SM> - what completion operations take place:
SM> - insert a few chars at point
SM> - bring up a list of candidates
SM> - ...
>> I think this should be unified as much as possible into a single
>> operation that takes place in any context, outside of the user's
>> control.

SM> Here I lost you.  Currently, the kind of operation can be:
SM>  - list candidates (completion-help-at-point)
SM>  - insert a few chars (completion-at-point)
SM>  - cycle through candidates (completion-at-point with
SM>    completion-cycle-threshold, or minibuffer-force-complete).
SM> AFAIK the users often like to have the choice between the three.
SM> Tho admittedly, TAB is the main entry point.

I was thinking of these as the effect of the operation, and the
operation is "completion DWIM."  The semantics here are a minefield and
there is a huge range of customizations available.

>> IOW this should be the place where Emacs standardizes to only one
>> completion/selection API, possibly through the
>> `completion-*' functions.

SM> And here I lost you as well: I thought this section was about commands
SM> and behaviors, whereas "API" to me means "functions" (as in "called from
SM> Elisp").

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> - what operations can be performed while the list of candidates is 
displayed:
SM>   - keep on editing as if the list was not displayed
SM>   - select among candidates with the mouse
SM>   - select with up/down
SM>   - ...
>> The current defaults for this are not consistent and were the original
>> reason for starting the thread.

SM> Hmm... Could you explain which parts are not consistent?

"Select with up/down" is not consistent between in-minibuffer and
in-buffer completion.  You can always go into the *Completions* buffer
and then use up/down, but up/down immediately have different effects
otherwise.  I think they should do the same thing, enter a special popup
as Dmitry and I described.

"Keep on editing" acts differently as well.

Mouse selection works the same way, I think.

>> The default here is tricky, since we have the in-buffer
>> vs. in-minibuffer split to consider.  I agree with Dmitry that
>> auto-narrowing the candidates is important by default;

SM> That should be easy to implement (tho admittedly, currently this will
SM> require 2 different implementations for in-buffer and in minibuffer).
SM> For the in-buffer case, it might be as simple as adding a call to
SM> completion-help-at-point at the right place.

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

>> the up/down selection is important too but must not interfere with
>> buffer motion when completing in a buffer of course.  If we can find
>> something consistent that works as a default in all the invocation
>> contexts, I think that would offer the biggest benefit to
>> Emacs usability.

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?  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> - how/when to update the list of completions and to pop it down.
>> That should be entirely internal to the API and not exposed, I think.

SM> "Internal to the API" is completely meaningless to me.  If it's not
SM> exposed, then it's not in the API (i.e. it's only in the
SM> chosen UI's implementation).

Right, sorry.  It should be internal to the implementation.

SM> - what Lisp function to call to display the list of elements.
SM> We currently don't really have something clear here.  IIUC this is the
SM> API part you care about (the rest is mostly behavior rather than API).
>> Yes, this is the API that should get called by any package (internal or
>> external) that wants to ask the user to interactively select completion
>> candidates or just one item from a list.

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.  This should work with
(interactive) calls, of course, as a common use case.

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?

Ted