Re: Emacs completion matches selection UI

[Stefan Monnier]

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.

Here I lost you.  Currently, the kind of operation can be:
 - list candidates (completion-help-at-point)
 - insert a few chars (completion-at-point)
 - cycle through candidates (completion-at-point with
   completion-cycle-threshold, or minibuffer-force-complete).
AFAIK the users often like to have the choice between the three.
Tho admittedly, TAB is the main entry point.
   
> IOW this should be the place where Emacs standardizes to only one
> completion/selection API, possibly through the
> `completion-*' functions.

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

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.

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

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

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

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

Usually, if it works for in-buffer, it works as well in the
minibuffer case.

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.

"Internal to the API" is completely meaningless to me.  If it's not
exposed, then it's not in the API (i.e. it's only in the
chosen UI's 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.

I still don't quite understand what you want here.  Are you thinking of
a function like x-popup-menu or display-completion-list?


        Stefan