bug#16555: 24.3.50; Company and CAPF: dealing with completion values containing extra text

[Dmitry Gutov]

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.

> FWIW,
> 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.