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: Wed, 31 Jan 2018 12:50:23 -0500 Message-ID: <87h8r1lxy8.fsf@ericabrahamsen.net> References: <87inbjo1y8.fsf@ericabrahamsen.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1517421281 26020 195.159.176.226 (31 Jan 2018 17:54:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 31 Jan 2018 17:54:41 +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 Wed Jan 31 18:54:37 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 1egwaT-0005a7-K7 for ged-emacs-devel@m.gmane.org; Wed, 31 Jan 2018 18:54:21 +0100 Original-Received: from localhost ([::1]:48212 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1egwcU-0005CI-AC for ged-emacs-devel@m.gmane.org; Wed, 31 Jan 2018 12:56:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48255) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1egwZL-0003no-40 for emacs-devel@gnu.org; Wed, 31 Jan 2018 12:53:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1egwZI-0000Vq-1B for emacs-devel@gnu.org; Wed, 31 Jan 2018 12:53:11 -0500 Original-Received: from [195.159.176.226] (port=48724 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1egwZB-0000SQ-ML for emacs-devel@gnu.org; Wed, 31 Jan 2018 12:53:07 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1egwWv-0001FQ-Gu for emacs-devel@gnu.org; Wed, 31 Jan 2018 18:50:41 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 64 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:WHvZb77za4mRNY8JA5YiwtDqhsk= 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:222335 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). > [ 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