emacs-devel
[Top][All Lists]
Advanced

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

Re: Split off some backends from Company?


From: Dmitry Gutov
Subject: Re: Split off some backends from Company?
Date: Thu, 14 Aug 2014 06:20:34 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

On 08/13/2014 04:38 PM, Stefan Monnier wrote:

Probably not: using yasnippet as a completion source is a questionable
decision, which each user should make themselves. It replaces the advertised
way to interact with yasnippet (type the snippet key, press TAB), and the
recommended way to use this backend is to group it with others, not by
itself (think `completion-table-merge' instead of
`completion-table-in-turn'), so putting it in
`completion-at-point-functions' would probably be misguided.

I see what you mean, but why does this need another package?
It seems the code could/should be in yasnippet, controlled by
something like a minor-mode.

It could be in yasnippet, but then it would implicitly depend on Company anyway. A minor mode would, again, be something like an on/off switch, and company-yasnippet requires manual configuration to be useful, and users probably have to pick a good combination for each major mode they intend to use it in.

And some users just bind a key sequence to this command (which all Company backend double as), to invoke instead of pressing TAB for yasnippet expansion. I guess this specific usage could be facilitated via a minor mode, but I don't know how popular it is.

Hmm, yes. I guess we could do that if the user explicitly
installed a backend package.

I think it's "should" rather than "could", because it's important for
the installation to be as straightforward as possible.

On the one hand, the simplest setup is desirable. On the other hand, `company-backends' is designed to be customized, and to allow users to mix backends, to there's no single way to use a specific backend (see https://github.com/iquiw/company-ghc#4note as an example of alternative setup). So the simplicity has to be balanced against the odds of users being forced to undo the automatic setup.

Further, there is a convention in the third-party developer community of not doing too much in autoloads ("installing the package shouldn't turn it on", or something along these lines). I don't entirely agree with it (here's one discussion on the subject: https://github.com/skeeto/skewer-mode/issues/22#issuecomment-18454897), but I prefer to do less, rather than more, when the choice is not obvious.



reply via email to

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