From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: emacs-devel@gnu.org
Subject: Re: elpa.gnu.org packages requiring external packages
Date: Tue, 06 Feb 2018 11:45:29 -0800 [thread overview]
Message-ID: <87fu6daome.fsf@ericabrahamsen.net> (raw)
In-Reply-To: 3adfa163-3238-09a0-a345-205babcfe9ef@yandex.ru
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).
next prev parent reply other threads:[~2018-02-06 19:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-30 7:22 elpa.gnu.org packages requiring external packages Glenn Morris
2018-01-30 14:08 ` Richard Stallman
2018-01-30 14:28 ` Eric Abrahamsen
2018-01-30 16:13 ` Stefan Monnier
2018-01-31 17:50 ` Eric Abrahamsen
2018-01-31 23:11 ` Stefan Monnier
2018-02-01 17:54 ` Eric Abrahamsen
2018-02-01 19:23 ` Stefan Monnier
2018-02-03 0:43 ` Eric Abrahamsen
2018-02-04 20:16 ` Dmitry Gutov
2018-02-06 19:45 ` Eric Abrahamsen [this message]
2018-02-02 13:49 ` Feng Shu
2018-02-02 16:12 ` Stefan Monnier
2018-01-31 1:25 ` Richard Stallman
2018-01-30 19:04 ` Glenn Morris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fu6daome.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.