Re: enabling company-capf support in cfengine.el

[Stefan Monnier]

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

OK.  Could you make a bug report listing these (3 so far) problematic
functions, and explaining (as much as you can remember) what kind of
problem they cause?
[ Don't waste too much time trying to remember what problem they cause:
  if you remember, great, but if not, it might be obvious when I look at
  it anyway.  ]
That will help me not forget.

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

Ah, I see in the rest of your answer than this is all about "not
waiting".  So, yes, the name should rather be :company-immediate or
something like that.  It could also be "integer or t".  And indeed, the
integer case is probably not needed.

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

Right.

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

Indeed, sorry.  I had not understood the purpose.  Apparently the
docstring's reference to `company-minimum-prefix-length' wasn't
sufficient for me to figure it out ;-)

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

How 'bout company-clang.el at first?
Could later be renamed to capf-clang.el, or cc-clang.el, or ... ?

> Would that hook addition be global,

Since company-clang is added globally to company-backends, yes, I'd
expect company-capf-clang to be added to the global part of
completion-at-point-functions as well.

> forcing clang-completion-function to include a major-mode check
> (hitherto unseen behavior in CAPF functions, AFAIK),

Don't know if it's already seen or not, but I don't see why it'd be
a problem.

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

I really don't see why it's hard:
- change company-clang.el so that it supports the "CAPF protocol" rather
  than the "company-backend protocol".
- actually make it support both protocols (with the help of
  company-capf to translate from the CAPF protocol to the other).
- in company.el (add-hook 'completion-at-point-function 'company-capf-clang)
  and add company-clang to company-backends if Emacs is too old to use
  company-capf.

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

But moving it to CAPF means that it becomes useful/usable not only for
Company for also for good ol' competion-at-point.


        Stefan