Re: Emacs completion matches selection UI

[Toby Cubitt]

On Mon, Jan 06, 2014 at 08:25:34AM +0400, Dmitry Gutov wrote:
> On 05.01.2014 20:04, Stefan Monnier wrote:
> >> a) `c-a-p-f' looks less accessible to the end user than `company-backends',
> >
> > That's because it's mostly not meant for the users to change, and that's
> > because users should not need to touch it.
> 
> I disagree. Two examples:
> 
> 1. I'm planning to write a new backend that would integrate with 
> Yasnippet. But it's not particularly useful as a stand-alone completion 
> function, because when the user types "if", they might want to either 
> expand it to "if (...) { }", or, for example, call a function whose name 
> starts with "if", and they should see both options. In Company terms, 
> that means that those backends should be merged: the first item in 
> `company-backends' will be a list with the names of these two backends 
> (or maybe more). Doing this programmatically for the user could be 
> fairly surprising, and, in the case of `c-a-p-f', opaque.

We could allow the COLLECTION argument to be a list of collections, that
then get merged by completion-at-point. I agree it's opaque.

> 2. We have two backends that are applicable in a similar set of major 
> modes: company-semantic and company-clang. We can check if we can use 
> either (by seeing if Semantic is enabled and by looking for the Clang 
> program), but if both are usable, user might want to prefer to use the 
> one or the other. How to let them pick? Providing a couple of minor 
> modes, where each would only enable/disable a specific backend/capf is 
> possible, but very clunky, as far as I'm concerned, and requires special 
> treatment. (Do I provide a minor mode for this backend function? How 
> about this other one?)

Presumably the user's supposed to write a function that returns whichever
capf they want to use, and add it to the c-a-p-f hook.

Or, brainstorming here, you could have a Company customization option
that lets them specify a backend preference order (including lists of
merged backends), and add a function to the c-a-p-f hook that chooses the
best applicable backend. (Though I guess this is essentially bypassing
c-a-p-f and substituting it with company-backends.)

My feeling is `completion-at-point-functions' is in principle general
enough to allow everything we want. But it's seriously creaking at the
seams. And it's only likely to get worse as we extend the PROPS argument
to cope with a richer set of UIs than the *Completions* buffer.

> > Nothing prevents us from providing
> > a "completion-at-point-merge-backends" function which takes a list of
> > completion-at-point-functions and returns a new 
> > completion-at-point-function.
> 
> Indeed. Although it seems to me that remembering where each candidate 
> came from (feature not yet present in Company either) would be harder to 
> implement, because completion functions are pretty much nameless as far 
> as the code using them is concerned. So propertizing the candidates with 
> (backend . company-elisp) won't work like it would in Company.
> 
> > company-backends and completion-at-point-functions don't work 100%
> > identically, but the differences are present only because of history.
> 
> I believe the main difference is "users customize it" vs. "users 
> generally don't know how to change it".

In Completion-UI, the "users don't change it" and "users customize it"
parts of the definitions are cleanly separated: the
`completion-ui-source-definitions' variable, which is modified by calling
the `completion-ui-register-source' macro from Elisp code to add a new
backend definition; and the `auto-completion-source-regexps',
`auto-completion-source-faces' and `auto-completion-source-functions'
variables, which have simple Customization interfaces.

c-a-p-f doesn't cleanly separate the things users might want to
customize, from the things only Elisp completion package authors should
have to deal with.

> > If Company had started with completion-at-point-functions it would
> > live very happily with it.
> 
> That's possible.

Or it would have been straining the limits of
completion-at-point-functions without company-backends to fall back on,
and c-a-p-f would have been extended until it looked more like
company-backends ;-)

T.
-- 
Dr T. S. Cubitt
Royal Society University Research Fellow
and Fellow of Churchill College, Cambridge
Centre for Quantum Information
DAMTP, University of Cambridge

email: address@hidden
web:   www.dr-qubit.org