Re: Emacs completion matches selection UI

[Ted Zlatanov]

On Sat, 4 Jan 2014 00:48:53 +0000 Toby Cubitt <address@hidden> wrote: 

TC> My feeling is once people decide what it is they want included in
TC> Emacs, and what the API should look like, re-purposing (parts of)
TC> the Company and/or Completion-UI code bases (maybe others too?) will
TC> be a big head start (assuming no copyright assignment roadblocks).

Yes, exactly.  Those are, in my mind, two cases that should work with
the API in order to prove its viability, and then we can try to fit
others.

>> - it should be possible to implement a generic frontend for completion
>> that both can use, and other tools like yasnippet can use IIUC.  The
>> eventual goal is to have "something" standard in Emacs that all such
>> packages (except perhaps helm, which is completely apart in its UI)
>> would use.  We have to ask Dmitry and Toby, among others, to guide us
>> with their experience of writing it once already, and we have to make
>> sure we don't end up with a solution no one wants to use :)

TC> Indeed. It would be nice to get input from the other completion package
TC> authors too (anything.el, auto-complete, icicles...)

anything.el became Helm and Thierry has been doing a great job
maintaining it.  I think he follows emacs-devel but as I mentioned I
have my doubts that Helm will fit any completion API.  It's very
integrated.  Maybe Thierry wants to say?

TC> Since it's the completion UI that will have to interpret and make use of
TC> the extras, one place to start is to think about what additional features
TC> the UI might want to provide, beyond selecting from a list of possible
TC> completions.

TC> Luckily, we have many existing completion frameworks to draw on for
TC> inspiration. At the moment, location data and various forms of
TC> documentation (e.g. type information in code completion, docstrings,
TC> etc.) are the only ones that spring to mind.

Add: feedback from frontend to backend (Predictive use case we
mentioned, needs API support through callbacks).  Pluggable completion
frontends (not in the API).  Dynamic limiting of completion candidates
as characters are typed (not in the API).

The backend should be able to provide hints about the data.  For
instance, "this is a list of ELisp symbols" could look different from
"this is a list of installable packages."  Also icons are important IMO,
based on the hints or the candidates.

TC> The keyword arguments to `completion-ui-register-source' are one starting
TC> point for seeing what additional properties might be needed, as are the
TC> corresponding APIs in Company, auto-complete, etc.

Can you or Dmitry compile a list?

TC> Also, if we want to allow users to optionally customize the completion UI
TC> per-backend (a la Completion-UI), there has to be some way of identifying
TC> backends in Customize. This seems necessary to me if the new API is to
TC> become the standard way of implementing a completion UI in Emacs. Think
TC> minibuffer completion, versus filename completion, versus predictive
TC> completion, versus elisp code completion etc, all of which might want to
TC> use slightly different UI options. Again, it might be enough to support a
TC> :name property (or some such) in the `completion-at-point-functions'
TC> PROPS plist.

The frontend UI should depend (in my mind) on three things: 1) the
invocation context as you showed; 2) the backend-provided hints about
the data as a whole; and 3) the backend-provided hints about each
completion candidate individually.  Does that make sense?  Some
frontends may ignore some or all of those things, but I think those are
the principal axis.  I don't know how those three things will be passed
to the frontend though, and when.

>> - the frontend choices made by the user should be able to feed back into
>> the data backend (the "predictive" use case)

TC> A few optional hooks/call-backs would very likely be sufficient. Again,
TC> the `completion-at-point-functions' PROPS plist would be the obvious
TC> place to specify them.

OK, this is your use case :)

>> - we have enough interest and support in this work that it's worth
>> undertaking in earnest after the code freeze.  The discussion should
>> remain on emacs-devel (based on the wide interest so far).
...
TC> (Note that I'm unlikely to have time to code anything myself until
TC> March/April, although the feature freeze will likely delay things until
TC> about then anyway. I'm happy to help in a more limited way before then,
TC> as time allows.)

Cool.  We seem to be moving towards a specific API, refining the current
Emacs internals, which is good.  I'd be OK with it looking like
completion-ui as long as it was at least somewhat backwards compatible
and could support the packages we mentioned.  To me, the clearest
indication of a good approach would be if both the Emacs core and
external packages were able to lose lines of code.

Ted