Re: Emacs completion matches selection UI

[Stephen J. Turnbull]

Ted Zlatanov writes:

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

Please explain what you mean by "unify".  If you mean
one-size-fits-all, I think that would be horrible.  There are
completion contexts where I don't want a list at all (dabbrev), and
others where I really, really do (browser completion of long URLs from
long histories).

If you simply mean there should be one function to invoke the
completion system, or a small number of such functions, with a "small"
number of parameters, I agree.  I think this points out the need for a
dispatching architecture, where the completion function exposed in the
API ends up dispatching to several handlers: construct the candidate
list, filter it, prioritize it, optionally present it to the user, and
optionally edit the target text ("auto-complete" suggests that edit
will always happen, but it's not always what is desired of a
completion mechanism -- eg, something I've occasionally wished for is
a "uniquifying completer", so that I don't accidentally duplicate
identifiers -- "you can check out but you can never leave" until the
item is unique in scope :-).

 > SM> - how to display the list of candidates:
 > SM>   - in a separate buffer
 > SM>   - at point, via clever overlay tricks
 > SM>   - at point, via a special frame
 > SM>   - at point, via a x-popup-menu
 > SM>   - ...
 > 
 > This should probably be customizable, but the default IMO should be
 > different between graphical and text mode, the way that `widget-choose'
 > does it.

If you architect the system as dispatching handlers to perform certain
tasks in sequence, you can postpone this decision (and, in fact, most
of the decisions you are discussing here, prematurely IMHO).  It seems
to me that the custom "selectors" for instancing faces (or whatever
the "keys" in a defface are called) would be a good choice for
specifying completion "list display" handlers.  Then you can start
with "one size fits all" with a selector of t and easily generalize.

The only nasty task in this architecture would be if it becomes
necessary to split a handler into two.  However, AFAICT from your
immediate agreement to the agenda Stefan set here, the three of us
(you, Stefan, me) agree 100% on what the options involved are, and I
suspect we could also agree quite quickly on what tasks deserve
separate handlers (some of the options probably need coordinated
decisions to avoid screwing each other up, so should not be in
separate handlers).  That's only 3 people, but I think it's good
evidence that agreement is going to be widespread, given how disparate
our opinions have been on everything else in this thread.

If somebody disagrees on the right setting for one of the options,
they just write their own handler; no need for discussion (unless they
want to propose it for default), and easy to experiment (as we've seen
there are a wide range of opinions on how to do this, experimentation
is an excellent idea).

The hard part is going to be designing selectors for each handler.
Some are going to be mostly dependent on display capability plus user
preference (the list display), others may be purely application-
dependent (selection of existing files is going to imply a list
generated by `directory-files'), so the selectors aren't going to be
one-size-fits-all.  But to start with the only handler selection
mechanism that needs to be implemented is t. :-)  Additional selection
criteria for a given handler can be added with only local surgery to
the dispatcher.

Steve