Re: elpa.gnu.org packages requiring external packages

["Feng Shu" <tumashu@163.com>]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> 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).

Maybe we should add a hanzi2pinyin package to elpa, for this
hanzi->pinyin feature is very important to Chinese emacs user.

>
>> [ 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

--