From: Eric Abrahamsen <eric@ericabrahamsen.net>
To: emacs-devel@gnu.org
Subject: Re: elpa.gnu.org packages requiring external packages
Date: Thu, 01 Feb 2018 12:54:15 -0500 [thread overview]
Message-ID: <87y3kcfveg.fsf@ericabrahamsen.net> (raw)
In-Reply-To: jwv4ln17ks7.fsf-monnier+gmane.emacs.devel@gnu.org
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).
>
> 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).
Okay, I'll take a look. I suppose we can defer building it until first
usage, etc.
>>> 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`.
Oh I'm all in favor, but I assumed it would be a no-no from a
dependency-graph point of view. If it doesn't matter, I can fold this
back into ebdb and just use `declare-function' with "ext:" to quiet the
compiler? In which case, I might as well just do the same for
`helm-marked-candidates' and leave it as-is?
I've also got these other silly little packages -- counsel-ebdb,
company-ebdb -- etc, should those all be reabsorbed? There are an awful
lot of counsel-* packages in there already.
Sorry, I'm just trying to figure out best policy for managing this kind
of stuff.
>> 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?
My observation is that the helm maintainers are not enthusiastic about
adding complexity without a good reason, and I would guess this wouldn't
count. I've opened an issue, though.
Eric
next prev parent reply other threads:[~2018-02-01 17:54 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 [this message]
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
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=87y3kcfveg.fsf@ericabrahamsen.net \
--to=eric@ericabrahamsen.net \
--cc=emacs-devel@gnu.org \
/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.