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

Previous Next

Full log

Message #14 received at 16555 <at> debbugs.gnu.org (full text, mbox):

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

> * Without the additional text property, a1 and a2 are considered equal, and
> only one of them is listed in the completions buffer.

Hmm??  AFAIK even with the text property, they are considered equal, so
it's odd that it would influence whether only one or both are displayed.
AFAIK in *Completions* "duplicates" are only eliminated if their
"text+annotation" is identical.

> And it looks to me that this approach is incompatible with the `value'
> command, if we want company-capf to support it.  Using the annotation
> function, it would know how to get from value to value + annotation,
> but not the other way around.

Agreed.

ELISP> (js2-time (all-completions "" obarray 'fboundp))
> 0.0121
ELISP> (js2-time (mapcar
>            (lambda (s)
>              (if (> (length s) 2)
>                  (propertize s 's (substring s (/ (length s) 2)))
>                s))
>            (all-completions "" obarray 'fboundp)))
> 0.1318

> The second measurement fluctuates between 130ms and 80ms, probably due to
> GC.  Maybe this is negligible, considering that on my machine
> that's a collection with 19000 elements, and most completion lists will be
> considerably smaller.

While I don't want to minimize the performance problem, you also have to
take into account the fact that the whole completion operation will
actually do something with those strings, so 19K candidates will
typically suffer from performance problems elsewhere.

> On the other hand, using `annotate' cleanly separates the "meat" in
> completion candidates from the extra text, which can be used to
> e.g. visualize them differently, maybe with different faces and alignments
> in the popup. As long as we solve the issue of uniqueness.

Conceptually, it does seem cleaner to me, indeed.

>> - `exit-function' would be used to insert the arglist after selecting
>> a candidate.
> Yes, `exit-function' is the best match for `post-completion', but I don't
> see which value of STATUS should be considered as okay for
> insertion.  `finished' seems to be a good candidate, but it does not seem to
> really correspond to when happens after `company-complete-selection' (the
> completion is inserted and the popup is closed).

It does correspond exactly.

> `finished' can only be the status when the inserted completion doesn't
> have any possible continuations in the completions table,

That description was from the point of view of "TAB-style completion".
In the case of company-complete-selection', we know that even if there
could be further continuations, the user's action indicates he doesn't
want those, so it really should be `finished'.

IOW the problem is one of how to better document the meaning of `finished'.

> The reverse is also true: being able not to insert the arguments list
> for a sole candidate can also be useful, and in Company user can do that at
> least by repeatedly using TAB (company-complete-common) instead of
> company-complete-selection'.

Then I guess that company-complete-common wouldn't want to pass
`finished' to the exit-function.


        Stefan

Previous Next

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