From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: elpa.gnu.org packages requiring external packages Date: Wed, 31 Jan 2018 18:11:22 -0500 Message-ID: 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 1517440330 6396 195.159.176.226 (31 Jan 2018 23:12:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 31 Jan 2018 23:12:10 +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 00:12:06 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 1eh1XO-0007o9-PH for ged-emacs-devel@m.gmane.org; Thu, 01 Feb 2018 00:11:30 +0100 Original-Received: from localhost ([::1]:38724 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eh1ZP-0005dK-Fw for ged-emacs-devel@m.gmane.org; Wed, 31 Jan 2018 18:13:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48157) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eh1Yf-0005Z1-FE for emacs-devel@gnu.org; Wed, 31 Jan 2018 18:12:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eh1Ya-0007nj-GL for emacs-devel@gnu.org; Wed, 31 Jan 2018 18:12:49 -0500 Original-Received: from [195.159.176.226] (port=60194 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eh1Ya-0007jS-8f for emacs-devel@gnu.org; Wed, 31 Jan 2018 18:12:44 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1eh1Vw-0002YF-5L for emacs-devel@gnu.org; Thu, 01 Feb 2018 00:10:00 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 49 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:Vlv3oYIxecvIks1yCHi0jz5eWJ4= 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:222343 Archived-At: >>>> > 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). >> 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`. > 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? Stefan