Re: elpa.gnu.org packages requiring external packages

[Eric Abrahamsen <eric@ericabrahamsen.net>]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>>     > ebdb-i18n-chn    # needs "pyim"
>
> BTW, I think Emacs comes with 99% of what's needed already (it does
> have a pinyin table and looking at pyim-hanzi2pinyin, there doesn't
> seem to be much more to it), so maybe we could add to Emacs a function
> equivalent to pyim-hanzi2pinyin and get rid of this dependency.

I'll take a look and see how close it already is. I'd be happy to add a
function to Emacs to do this or, if it's a real no-brainer, just add it
to EBDB and remove this dependency (and probably the whole package).

> [ Of course, we should also try and get pyim.el into GNU ELPA, but those
>   two are orthogonal.  ]
>
>>>     > helm-ebdb        # needs "helm"
>
> Clearly, getting Helm into GNU ELPA would be great.
>
> Also, looking at the code I see 2 dependencies:
> - the helm-ebdb function uses helm-other-buffer: so the helm-ebdb
>   function is basically a specialized entry point into Helm, so it is
>   useless without Helm.
> - half the other functions call helm-marked-candidates.
>
> So, if we could get rid of the second dependency, I'd argue that the
> helm-ebdb package could be useful on its own (i.e. even without Helm),
> for example it could be used with some (hypothetical) other
> Helm-like framework.
>
> IOW if we could get rid of the second dependency, then I think it would
> make sense to remove `helm` as a dependency (and probably just merge
> helm-ebdb into ebdb).  So my question here is: why do we need to call
> helm-marked-candidates?

I don't quite understand -- the package is useless without the call to
`helm-other-buffer' (that's the whole point), so how could I remove
that, or fold this into ebdb? I would need to call that function at some
point no matter what. Or do you mean let the user set a customization
option like (setq ebdb-completion-backend 'helm) and then let it blow up
if they don't have helm installed?

> Is there some way to get Helm to pass us the list of candidates as an
> argument (i.e. pass us what we compute via (or (helm-marked-candidates)
> (list candidate)))?  If not, maybe we should make this a feature request
> in Helm, to make the API between Helm and its backend functions such
> that the backend functions don't need to call Helm function.

It's possible to create helm sources without using any actual helm
functions: the sources can either be created as classes, which obviously
depends on helm, or as alists, which doesn't. The problem is the list of
"actions" you can take on completion candidates: if you create the
source with a plain alist, the action functions only act on a single
candidate. If you want the ability to act on multiple marked candidates,
you need to call that function yourself (though now I see the code in
this package is broken, ugh).

I think the only way around that would be to ask the helm maintainers to
allow some sort of flag to be set in the alist definition, saying "these
actions should accept all the marked candidates". I'm not too optimistic
they'd do that.

Eric