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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 16555-done <at> debbugs.gnu.org
Subject: bug#16555: 24.3.50; Company and CAPF: dealing with completion values containing extra text
Date: Tue, 28 Jan 2014 20:34:34 -0500

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

Hmm... I guess you're right.

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

Agreed.

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

No, no, feel free to think out loud.  I just wasn't sure if I'd missed
something or what.

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

So, IIUC the conclusion is "if the string's chars is not enough, you
have to store the extra info in text-properties".  Not sure where we
could put this info, but if you can think of a place, feel free to add it.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.