emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: enabling company-capf support in cfengine.el


From: Dmitry Gutov
Subject: Re: enabling company-capf support in cfengine.el
Date: Mon, 20 Jan 2014 02:13:26 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]