Re: enabling company-capf support in cfengine.el

[Dmitry Gutov <dgutov@yandex.ru>]

On 19.01.2014 22:19, Stefan Monnier wrote:
>> Sometime ago I've been told that RMS dislikes Clang strongly enough to
>> oppose inclusion of any code using it in Emacs.
>
> AFAIK Clang is Free Software.  So, I don't see a valid reason to reject
> inclusion of company-clang or equivalent into Emacs.  If it's in GNU
> ELPA it's (virtually) in Emacs already anyway (we use the same rules for
> the two, specifically so we can easily move code from one to the other).

Richard's argument in the thread linked by David was not based on 
Clang's legal status, other than it being distributed under a 
non-copyleft license.

Since that argument doesn't make sense to me, I won't claim to fully 
understand it, or whether there is any difference between Emacs and GNU 
ELPA, as far as that argument is concerned.

>> Unless it has changed (or is no longer a major factor), separating the code
>> from Company won't be particularly valuable.
>
> My interest is in making Company into nothing more than an alternative
> UI.  All the backends would be separate and usable as much by Company as
> by completion-at-point.

I'm interested in this general direction as well, as long as the 
migration causes no regression in features available to Company users.

But I think moving backends that have no existing corresponding 
completion functions in Emacs core is low priority.

>> Clang specifically? That's why I suggested another minor mode.
>
> Yes, ultimately clang-completion should be a separate package enabled
> separately.  In any case I don't think any of those issues are serious
> enough to be a reason not to make the clang backend work via CAPF.

Ok. Then my main point is, there's no reason to do the CAPF conversion 
until it's in a separate package/minor mode. The conversion itself 
should be easy.

And ideally, the splitting would be performed by someone who works with 
C/C++ and Clang with any regularity. I.e. not myself. :)