From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "Feng Shu" Newsgroups: gmane.emacs.devel Subject: Re: elpa.gnu.org packages requiring external packages Date: Fri, 02 Feb 2018 21:49:43 +0800 Message-ID: <87zi4ro614.fsf@163.com> 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 1517585028 2728 195.159.176.226 (2 Feb 2018 15:23:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Feb 2018 15:23:48 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.91 (gnu/linux) Cc: emacs-devel@gnu.org To: Eric Abrahamsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 02 16:23:43 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 1ehdBB-0006mN-Ev for ged-emacs-devel@m.gmane.org; Fri, 02 Feb 2018 16:23:05 +0100 Original-Received: from localhost ([::1]:36459 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehdDC-0002or-E3 for ged-emacs-devel@m.gmane.org; Fri, 02 Feb 2018 10:25:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46046) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehcgd-0007Br-8q for emacs-devel@gnu.org; Fri, 02 Feb 2018 09:51:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ehcgZ-0007Cz-BX for emacs-devel@gnu.org; Fri, 02 Feb 2018 09:51:31 -0500 Original-Received: from m12-13.163.com ([220.181.12.13]:59697) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehcgY-0007C1-I5 for emacs-devel@gnu.org; Fri, 02 Feb 2018 09:51:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=163.com; s=s110527; h=From:Subject:Date:Message-ID:MIME-Version; bh=AEt1b sduffCzbC6/P1or6qTkuPsnmDY/EdvEu9J6mYY=; b=CCP0ENi8GJW4tVCTrka17 83NKPqMfuFTpay60KJVjCsaYrx7bsLT6tHhOoyyLeD7b4ebn/GdwX61ChhhqaTS5 GXXO0I2yQ2JuXlrUp2toqeRvQLoVka74uTFDFAQDbzIssbc0BHqTYfSmvjiDsnkr yq5jlZHRJrbA8G8Tpfu+Ts= Original-Received: from tumashu (unknown [36.149.168.110]) by smtp9 (Coremail) with SMTP id DcCowADHotZ6bHRa40xyDg--.44388S2; Fri, 02 Feb 2018 21:49:47 +0800 (CST) In-Reply-To: <87h8r1lxy8.fsf@ericabrahamsen.net> (Eric Abrahamsen's message of "Wed, 31 Jan 2018 12:50:23 -0500") X-CM-TRANSID: DcCowADHotZ6bHRa40xyDg--.44388S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxXry8CF1rAr43Gw4fWFWUtwb_yoW5Zw1xpa 9Y9FyFk34kXF42yw1xAr1fGrWxAws8CFW5Jrn5GryUZwn8Wrn2qFWrt3Wj9F9rCrZ5Aw1j qa1j9rnxArWqva7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07jeVbkUUUUU= X-Originating-IP: [36.149.168.110] X-CM-SenderInfo: 5wxpt2lkx6il2tof0z/1tbiRRzg1Fl9itVCwwAAsX X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 220.181.12.13 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:222397 Archived-At: Eric Abrahamsen writes: > 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). Maybe we should add a hanzi2pinyin package to elpa, for this hanzi->pinyin feature is very important to Chinese emacs user. > >> [ 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 --