From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.devel Subject: Re: elpa.gnu.org packages requiring external packages Date: Thu, 01 Feb 2018 12:54:15 -0500 Message-ID: <87y3kcfveg.fsf@ericabrahamsen.net> References: <87inbjo1y8.fsf@ericabrahamsen.net> <87h8r1lxy8.fsf@ericabrahamsen.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1517507739 13501 195.159.176.226 (1 Feb 2018 17:55:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Feb 2018 17:55:39 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 01 18:55:35 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ehJ59-00032G-U0 for ged-emacs-devel@m.gmane.org; Thu, 01 Feb 2018 18:55:32 +0100 Original-Received: from localhost ([::1]:51386 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehJ7A-0002fT-TQ for ged-emacs-devel@m.gmane.org; Thu, 01 Feb 2018 12:57:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47088) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehJ6a-0002em-Fh for emacs-devel@gnu.org; Thu, 01 Feb 2018 12:57:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ehJ6X-0006Ng-Dn for emacs-devel@gnu.org; Thu, 01 Feb 2018 12:57:00 -0500 Original-Received: from [195.159.176.226] (port=56766 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ehJ6X-0006Kh-74 for emacs-devel@gnu.org; Thu, 01 Feb 2018 12:56:57 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1ehJ4B-0007yz-Ha for emacs-devel@gnu.org; Thu, 01 Feb 2018 18:54:31 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 70 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:NfalloTcj+3g8vwxJsYkbvbR4rU= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:222358 Archived-At: Stefan Monnier 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