[Top][All Lists]

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

Re: elpa.gnu.org packages requiring external packages

From: Dmitry Gutov
Subject: Re: elpa.gnu.org packages requiring external packages
Date: Sun, 4 Feb 2018 23:16:42 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Thunderbird/58.0

On 2/3/18 03:43, Eric Abrahamsen wrote:

company primarily does popup-on-a-timer;

popup-on-a-timer is irrelevant. company supports completion-at-point-functions via company-capf.

The only major feature that completion-at-point-functions don't get (that company backends do) is asynchronous operation.

> I think calling it as an
> explicit completion command (while supported) isn't how it's expected
> to be used.

M-x company-<backend> is a well-established way of using it (not the most popular one, of course).

And overall, I really wish someone could sit down, take the ivy,
company, helm, and completion-at-point-function APIs and design a new
API which can be used by all of those UIs so you don't have to implement
N different slight variations of the same thing.

It would be nice to see some input from Ivy's author: it does support asynchronous operation, and even operating on an incomplete set of results. That's something CAPF does not have yet. Add fuzzy matching, and that's basically everything we want such API to have.

But they do their things in such different ways. Some work on a timer
with a popup (company), others tie into the existing completion
mechanisms (helm and ivy), and others provide their own versions of
basic Emacs commands (helm and counsel). How much unification is

company-capf is an example of one such unification. And given a powerful-enough API, all packages could have the ability, at least, to switch to it.

reply via email to

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