[Top][All Lists]

[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: Sun, 19 Jan 2014 18:44:21 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

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

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.

reply via email to

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