Re: Emacs completion matches selection UI

[Ted Zlatanov <tzz@lifelogs.com>]

On Sat, 21 Dec 2013 12:32:19 +0900 "Stephen J. Turnbull" <stephen@xemacs.org> wrote: 

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

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

The context will be respected either by being a parameter or being
inferred from the invocation, or both.  The idea is to have a single API
call for all contexts, not to make the operation's effect the same in
all contexts.

SJT> If you simply mean there should be one function to invoke the
SJT> completion system, or a small number of such functions, with a "small"
SJT> number of parameters, I agree.

Right, exactly.

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

See the company-mode frontend/backend split, for instance.  This is a
common design.  I don't have a strong opinion about the whole data flow,
I just want to improve the frontend right now, but perhaps these
opportunities will appear if the project takes off.

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.

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

I think postponing these design decisions would not be optimal, but I
understand the temptation and will listen to advice when we get to that
point.

SJT> The only nasty task in this architecture would be if it becomes
SJT> necessary to split a handler into two.  However, AFAICT from your
SJT> immediate agreement to the agenda Stefan set here, the three of us
SJT> (you, Stefan, me) agree 100% on what the options involved are, and I
SJT> suspect we could also agree quite quickly on what tasks deserve
SJT> separate handlers (some of the options probably need coordinated
SJT> decisions to avoid screwing each other up, so should not be in
SJT> separate handlers).

I still need a clear agreement from Stefan before proceeding.  Then I
will try to get a team together and work outside of the normal Emacs
commit flow so we can iterate quickly.

SJT> That's only 3 people, but I think it's good evidence that agreement
SJT> is going to be widespread, given how disparate our opinions have
SJT> been on everything else in this thread.

Discussions of UI improvements are one of the rare occasions where
everyone has at least one strong opinion.  I think this one has been
quite smooth, I've only thrown one keyboard out the window and AFAIK
I'm not yet in Stefan's killfile ;)

Ted