From: "Feng Shu" <tumashu@163.com>
To: Eric Abrahamsen <eric@ericabrahamsen.net>
Cc: emacs-devel@gnu.org
Subject: Re: elpa.gnu.org packages requiring external packages
Date: Fri, 02 Feb 2018 21:49:43 +0800 [thread overview]
Message-ID: <87zi4ro614.fsf@163.com> (raw)
In-Reply-To: <87h8r1lxy8.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Wed, 31 Jan 2018 12:50:23 -0500")
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
--
next prev parent reply other threads:[~2018-02-02 13:49 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-30 7:22 elpa.gnu.org packages requiring external packages Glenn Morris
2018-01-30 14:08 ` Richard Stallman
2018-01-30 14:28 ` Eric Abrahamsen
2018-01-30 16:13 ` Stefan Monnier
2018-01-31 17:50 ` Eric Abrahamsen
2018-01-31 23:11 ` Stefan Monnier
2018-02-01 17:54 ` Eric Abrahamsen
2018-02-01 19:23 ` Stefan Monnier
2018-02-03 0:43 ` Eric Abrahamsen
2018-02-04 20:16 ` Dmitry Gutov
2018-02-06 19:45 ` Eric Abrahamsen
2018-02-02 13:49 ` Feng Shu [this message]
2018-02-02 16:12 ` Stefan Monnier
2018-01-31 1:25 ` Richard Stallman
2018-01-30 19:04 ` Glenn Morris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zi4ro614.fsf@163.com \
--to=tumashu@163.com \
--cc=emacs-devel@gnu.org \
--cc=eric@ericabrahamsen.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.