Re: elpa.gnu.org packages requiring external packages

[Stefan Monnier]

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

AFAICT the pinyin table is only kept in the quail table: quail tables
are somewhat similar to keymaps, so they work well to incrementally map
a sequence of ASCII chars to the possible chinese characters, but for
pyim-hanzi2pinyin we'll need to traverse this table to build a "reverse
table" (most likely represented as a char-table).

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

The helm-ebdb function is useless without Helm, yes.  But that doesn't
mean that it has to appear as a dependency on the containing package.

Imagine if font-lock, outline, newcomment, and indent were packaged as
ELPA packages.  Would you want separate python-font-lock,
python-outline, python-comment, and python-indent packages each with its
corresponding dependency?

I think it makes a lot of sense to fold helm-ebdb into the ebdb package,
without adding `helm` as a dependency.  This way, users of Helm and EBDB
won't have to additionally install helm-ebdb to enjoy the combination of
the two: just by installing `ebdb` and `helm` they'll get `helm-ebdb`.

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

Something along these lines sounds good, yes.

> I'm not too optimistic they'd do that.

Why not?


        Stefan