Re: enabling company-capf support in cfengine.el

[Dmitry Gutov]

On 17.01.2014 15:04, Stefan Monnier wrote:
> Whenever you bump into such problems, do report them.  I'll take a look
> at the above two.

Thank you. Another one that I've noticed is `message-completion-function'.

> > > BTW, the next step would be to supplant other company backends, like
> > > we've done with company-elisp: company-css, company-nxml, and
> > > company-semantic look like prime candidates.
> > Indeed.  Although I'm not sure what would be an appropriate counterpart in
> > CAPF for `company-semantic--pre-prefix-length'.
>
> You mean, what should be the counterpart to:
>
>     cannot \(e.g. if it is in the middle of a string\).  Instead of a string,
>     the back-end may return a cons where car is the prefix and cdr is used in
>     `company-minimum-prefix-length' test.  It's either number or t, in which
>     case the test automatically succeeds.
>
> A straightforward option might be to have CAPF return
> a new :company-prefix-length-offset property which is then added to the
> prefix length by company-capf.

Note the option of returning `t', it doesn't fit the proposed name 
(-prefix-length).

And actually, I'm not aware of any users of `company-semantic' (though 
there probably are some), whereas `company-clang' uses that `t' return 
value after a user request, which I think makes more sense. Maybe we 
should deprecate the numeric cdr altogether.

And when the choice is between returning `t' or nothing, the choice of 
whether idle completion is appropriate at point is made only by the 
backend. For example, in C-based languages, if the current word goes 
after "." or "->", it's quite likely the choice of completions is known 
and limited, and many users, used to the popular IDE behavior, even like 
when the idle completion popup is displayed right after typing "." or 
"->" (and waiting a certain fraction of a second).

So yes, a new property might be appropriate, but with different semantics.

>  From a more CAPF-centric point of view, in the case of Semantic, another
> option is to return as prefix not "ch" but "fr->ch", and then specify
> a boundary between "fr->" and "ch".

Maybe. But the notion of completion boundaries is unrelated to idle 
completion, and the latter is the sole purpose of that return value.

> > With Semantic, we also have the question of alternatives.  At the moment,
> > company-semantic' goes before `company-clang', so that if semantic-mode is
> > enabled, the former is used, and otherwise, the latter.
>
> That's easy to solve: turn company-clang into its CAPF equivalent, then
> place it within completion-at-point-functions after the Semantic one.

Which body of code would contain that clang-completion-function, and 
perform the adding? Would that hook addition be global, forcing 
clang-completion-function to include a major-mode check (hitherto unseen 
behavior in CAPF functions, AFAIK), or would it iterate over applicable 
major mode hooks?

Anyway, as I see it, none of the options would provide a smooth 
transition from company-clang being included in company-backends. The 
users will have to install a package, enable a minor mode, or do 
something equivalent.

Guess a simpler solution would be to keep company-clang as-is, but move 
it behind company-capf.