[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: Mon, 27 Jan 2014 00:52:44 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 26.01.2014 08:23, Stefan Monnier wrote:
* Including extra text in completion table seems like it won't mesh well
   with the completion-at-point-functions interface, and specifically
   with the completion-at-point as the frontend. How would one write a
   CAPF function for clang or eclim with argument lists in mind?

 From a CAPF point of view, I think it would work as follows:
- all-completions would return the "cropped" names.
- `annotate-function' would be used to add the arglists to *Completions*.

I played with this a bit, and looks like the proper way to make this work with the current completion-at-point code is to use text properties. I propertize the completions, and then the annotation function looks up the text property:

(add-hook 'completion-at-point-functions
           (lambda ()
             (let ((bounds (bounds-of-thing-at-point 'symbol)))
               (when bounds
                  (car bounds)
                  (cdr bounds)
                  (list a1 a2 a3)
                  :annotation-function #'annota)))) nil t)

(setq a1 (propertize "aaa" 'a "a1")
      a2 (propertize "aaa" 'a "a2")
      a3 (propertize "aab" 'a "a3"))

(defun annota (s)
  (format "(%s)" (get-text-property 0 'a s)))

Using a hash table surprizingly didn't work, because:

* Without the additional text property, a1 and a2 are considered equal, and only one of them is listed in the completions buffer. * If the hash table uses the `eq' test, lookup fails because the strings passed to the annotation function are not the same objects as those we return in the completions table. * If the hash table uses the `equal' test, naturally it can't distinguish between a1 and a2 (lookup returns "a2" for both).

Is that how it's supposed to work?

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.

Using `value' as described, aside from smoother transition from the current behavior, appealed to me because it allows to defer the string munging to the last possible moment, thus saving in performance on all strings that weren't displayed, when the candidates list is large.

But here's an extreme example, of sorts:

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

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.

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.

- `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). `finished' can only be the status when the inserted completion doesn't have any possible continuations in the completions table, whereas we obviously want to be able to do arglist insertion for these cases, too.

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

reply via email to

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