[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: Mon, 06 Jan 2014 08:25:34 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 05.01.2014 20:04, Stefan Monnier wrote:
a) `c-a-p-f' looks less accessible to the end user than `company-backends',

That's because it's mostly not meant for the users to change, and that's
because users should not need to touch it.

I disagree. Two examples:

1. I'm planning to write a new backend that would integrate with Yasnippet. But it's not particularly useful as a stand-alone completion function, because when the user types "if", they might want to either expand it to "if (...) { }", or, for example, call a function whose name starts with "if", and they should see both options. In Company terms, that means that those backends should be merged: the first item in `company-backends' will be a list with the names of these two backends (or maybe more). Doing this programmatically for the user could be fairly surprising, and, in the case of `c-a-p-f', opaque.

2. We have two backends that are applicable in a similar set of major modes: company-semantic and company-clang. We can check if we can use either (by seeing if Semantic is enabled and by looking for the Clang program), but if both are usable, user might want to prefer to use the one or the other. How to let them pick? Providing a couple of minor modes, where each would only enable/disable a specific backend/capf is possible, but very clunky, as far as I'm concerned, and requires special treatment. (Do I provide a minor mode for this backend function? How about this other one?)

`company-backends' in contrast contains a mishmash of things, 90% of
which is irrelevant to any given situation.

That's just the default value.

Users can set it to smaller lists in specific major modes to make it more "relevant" if they want, but the relevancy check is fast, so by default the list is global and is indeed a mishmash, to make getting started easier.

Nothing prevents us from providing
a "completion-at-point-merge-backends" function which takes a list of
completion-at-point-functions and returns a new completion-at-point-function.

Indeed. Although it seems to me that remembering where each candidate came from (feature not yet present in Company either) would be harder to implement, because completion functions are pretty much nameless as far as the code using them is concerned. So propertizing the candidates with (backend . company-elisp) won't work like it would in Company.

company-backends and completion-at-point-functions don't work 100%
identically, but the differences are present only because of history.

I believe the main difference is "users customize it" vs. "users generally don't know how to change it".

If Company had started with completion-at-point-functions it would live
very happily with it.

That's possible.

reply via email to

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