[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs completion matches selection UI

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

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.

reply via email to

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