Re: Emacs completion matches selection UI

[Dmitry Gutov]

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.

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?)

> `company-backends' in contrast contains a mishmash of things, 90% of
> which is irrelevant to any given situation.

That's just the default value.

Users can set it to smaller lists in specific major modes to make it 
more "relevant" if they want, but the relevancy check is fast, so by 
default the list is global and is indeed a mishmash, to make getting 
started easier.

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

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

That's possible.