Re: elpa.gnu.org packages requiring external packages

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Dmitry Gutov <dgutov@yandex.ru> 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).