[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: elpa.gnu.org packages requiring external packages
From: |
Stefan Monnier |
Subject: |
Re: elpa.gnu.org packages requiring external packages |
Date: |
Tue, 30 Jan 2018 11:13:35 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
>> > 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.
[ 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?
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.
Stefan
Re: elpa.gnu.org packages requiring external packages, Glenn Morris, 2018/01/30