|
From: | Dmitry Gutov |
Subject: | Re: Emacs completion matches selection UI |
Date: | Sun, 05 Jan 2014 08:08:28 +0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 |
On 04.01.2014 07:54, Stefan Monnier wrote:
In `company-capf', we iterate though the completion-at-point-functions each time. This works, and works well enough, since the "does it fit" code is usually fast, but it looks fairly bizarre to me, logically.Agreed. It was just "the easy" way to fit it in.
Can't we save the last `company--capf-data' value in the `prefix' case? Company only calls the rest of the cases after it, and only when the returned value is non-nil. Since prefix value has to stay fresh, the cached data will also be.
"The right thing" would be to replace company-backends with completion-at-point-functions.
I'm not convinced yet that it's the right thing to do.a) `c-a-p-f' looks less accessible to the end user than `company-backends', and the former isn't even a defcustom. The structure of the latter, on the other hand, is easier to read and modify in users' init files and major mode hooks.
The Company backends are also easier to spot among other functions in the packages that contain them. The names of the c-a-p-functions used by e.g. IELM follow no discernible convention.
b) There's no direct analog to "merged" Company backends in `completion-at-point-functions'. `company-backends' can contain list values, and `company--multi-backend-adapter' handles the merging of the returned data.
I'm also tinkering with the idea to make individual candidates remember the backends they came from (using text properties, most likely), so that we will know which backend's function to use with this candidate. Calling `post-completion' action from the wrong backend would be the best example of how it's currently broken.
[Prev in Thread] | Current Thread | [Next in Thread] |