[Top][All Lists]

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

Re: elpa.gnu.org packages requiring external packages

From: Feng Shu
Subject: Re: elpa.gnu.org packages requiring external packages
Date: Fri, 02 Feb 2018 21:49:43 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.91 (gnu/linux)

Eric Abrahamsen <address@hidden> writes:

> Stefan Monnier <address@hidden> 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


reply via email to

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