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

On 17.01.2014 15:04, Stefan Monnier wrote:
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'.

BTW, the next step would be to supplant other company backends, like
we've done with company-elisp: company-css, company-nxml, and
company-semantic look like prime candidates.
Indeed.  Although I'm not sure what would be an appropriate counterpart in
CAPF for `company-semantic--pre-prefix-length'.

You mean, what should be the counterpart to:

    cannot \(e.g. if it is in the middle of a string\).  Instead of a string,
    the back-end may return a cons where car is the prefix and cdr is used in
    `company-minimum-prefix-length' test.  It's either number or t, in which
    case the test automatically succeeds.

A straightforward option might be to have CAPF return
a new :company-prefix-length-offset property which is then added to the
prefix length by company-capf.

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

And actually, I'm not aware of any users of `company-semantic' (though there probably are some), whereas `company-clang' uses that `t' return value after a user request, which I think makes more sense. Maybe we should deprecate the numeric cdr altogether.

And when the choice is between returning `t' or nothing, the choice of whether idle completion is appropriate at point is made only by the backend. For example, in C-based languages, if the current word goes after "." or "->", it's quite likely the choice of completions is known and limited, and many users, used to the popular IDE behavior, even like when the idle completion popup is displayed right after typing "." or "->" (and waiting a certain fraction of a second).

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

 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.

With Semantic, we also have the question of alternatives.  At the moment,
company-semantic' goes before `company-clang', so that if semantic-mode is
enabled, the former is used, and otherwise, the latter.

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? Would that hook addition be global, forcing clang-completion-function to include a major-mode check (hitherto unseen behavior in CAPF functions, AFAIK), or would it iterate over applicable major mode hooks?

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.

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

reply via email to

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