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: Tue, 30 Jan 2018 11:13:35 -0500 Message-ID: References: <87inbjo1y8.fsf@ericabrahamsen.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1517328792 13479 195.159.176.226 (30 Jan 2018 16:13:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Jan 2018 16:13:12 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eric Abrahamsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 30 17:13:08 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 1egYWd-00022N-UP for ged-emacs-devel@m.gmane.org; Tue, 30 Jan 2018 17:12:48 +0100 Original-Received: from localhost ([::1]:46080 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1egYYe-0006GX-Rj for ged-emacs-devel@m.gmane.org; Tue, 30 Jan 2018 11:14:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40264) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1egYXe-0006G3-Gu for emacs-devel@gnu.org; Tue, 30 Jan 2018 11:13:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1egYXY-0003R6-OW for emacs-devel@gnu.org; Tue, 30 Jan 2018 11:13:50 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:37397) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1egYXY-0003Qb-II for emacs-devel@gnu.org; Tue, 30 Jan 2018 11:13:44 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w0UGDaL6012156; Tue, 30 Jan 2018 11:13:36 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id E1C866027F; Tue, 30 Jan 2018 11:13:35 -0500 (EST) In-Reply-To: <87inbjo1y8.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Tue, 30 Jan 2018 09:28:47 -0500") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6211=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6211> : inlines <6347> : streams <1777540> : uri <2582840> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:222315 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. [ 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? 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. Stefan