Re: enabling company-capf support in cfengine.el

[Dmitry Gutov]

On 19.01.2014 04:37, Stefan Monnier wrote:
> 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?

Done: http://debbugs.gnu.org/16496

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

I'll have to think about the name more. Maybe Completion-UI gives some 
inspiration.

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

Sometime ago I've been told that RMS dislikes Clang strongly enough to 
oppose inclusion of any code using it in Emacs.

Unless it has changed (or is no longer a major factor), separating the 
code from Company won't be particularly valuable. Ours isn't a very 
sophisticated integration anyway, there are other packages doing more, 
such as spinning up a persistent server to eliminate the latency of 
launching new process and scanning all project files anew each time. 
Alas, they're all using auto-complete ATM.

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

Yeah, OK.

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

This is doable, yes.

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

Would it be at the top-level? I.e. whenever you have company.el loaded, 
the global value of completion-at-point-functions will include 
company-capf-clag. Sounds invasive.

Doing it in global-company-mode is not an option, I believe 
(define-globalized-minor-mode has no BODY argument), and even if it 
were, the users don't have to call this function, they can use 
company-mode directly.

If we're doing it inside company-mode function body, we'll have to 
change the local value instead.

Two last options would look weird either way: why would company-mode 
function concern itself with the value of completion-at-point-functions, 
and Clang specifically? That's why I suggested another minor mode.

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

Would a Company user benefit from this, really? I'd like to hear from 
one person that would first.

As long as (add-hook 'completion-at-point-function 'company-capf-clang) 
is only done when company-mode is enabled, there's really not much benefit.