[Top][All Lists]

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

Re: elpa.gnu.org packages requiring external packages

From: Eric Abrahamsen
Subject: Re: elpa.gnu.org packages requiring external packages
Date: Tue, 06 Feb 2018 11:45:29 -0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Dmitry Gutov <address@hidden> writes:

> 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
>> possible?
> 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.

I think I came off more skeptical than I meant to here. I really was
just curious how this would work. It's not an area of Emacs I've spent
much time with (and am not likely to).

reply via email to

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