[Top][All Lists]

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

bug#16555: 24.3.50; Company and CAPF: dealing with completion values con

From: Dmitry Gutov
Subject: bug#16555: 24.3.50; Company and CAPF: dealing with completion values containing extra text
Date: Wed, 29 Jan 2014 00:51:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 29.01.2014 00:04, Stefan Monnier wrote:
CAPF needs to improve the annotation
support, indeed.  I don't think the current annotation-function is
sufficient, since there are different kinds of annotations.  E.g. adding
"<f>" is not the same as adding "(int x, float y, Vector<String>)" for
simple reasons of screen real estate, so in some UIs you'd want to
display both, while in others you'd only want the short one.

I'm not sure differentiating between them would be beneficial. We already have "full document" annotation (company-doc-buffer), "one-line" annotation (company-docsig), and just "annotation" itself. If we're going to differentiate between different kinds of short annotations, this will make 4 different functions a backend would need to define to describe a candidate with words.

FWIW, "(int x, float y, Vector<String>)" looks short enough to me. In Ruby, it often looks like "(table_name, column_name, [options])", which isn't too long and still allows completion-at-point display candidates in two columns.

We could consider it a bug, though (that annotation-function is called with
different objects).

Not really: the "objects" you're talking about are returned by the
completion-table, i.e. they cover at most one "field" (in the
completion-boundaries sense), whereas completion-all-completions returns
strings that can span several fields, so clearly they can't always be
`eq' to something returned by the completion-table.

I see. Then I'm out of ideas here, and using text properties, as non-obvious that is, indeed remains the best option.

The idea is rather to let the backend provide more kinds of annotations
and let the UI choose which one to use.  E.g. icomplete-mode doesn't
want any annotation at all, because its screen real-estate is
very limited.  So completion-all-completions can't blindly add annotations.

Thanks for pointing that out.

Come to think of it, company-backends should be able to use a hash-table
with `eq' test maybe already, or if I massage the code a little. The major
question for me was about uniqueness, and looks like, yes, doing
delete-consecutive-dups' after fetching all annotations should be fast
enough (and this approach even has some space for optimization). So that
leaves a problem with CAPF.

That sounded like "thinking out loud for myself".  I don't know what you
wanted to say nor how that relates to CAPF.

It was. Sorry if it's out of place.
I filed this bug for discussing a new feature in both Company and CAPF, and that was me summing up the (one-sided) discussion of it on the Company side. So, closing.

minibuffer-completion-help uses `sort' on the "annotated completions"
and then display-completion-list uses delete-consecutive-dups (tho hand
written into the loop).

Yes, delete-consecutive-dups in Company is also inlined (in `company-calculate-candidates'), we couldn't use the function itself anyway, cause it's 24.4-only.

It could be an either/or specification: if annotation-function is defined,
use it, otherwise, look up the `annotation' property.

I think that in most cases the annotation function will want to do some
work rather than just return the content of the annotation (as in the
sample code in my previous message).

Hm, yes, indeed.

reply via email to

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