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: Fri, 02 Feb 2018 16:43:38 -0800 Message-ID: <87y3ka6gxx.fsf@ericabrahamsen.net> References: <87inbjo1y8.fsf@ericabrahamsen.net> <87h8r1lxy8.fsf@ericabrahamsen.net> <87y3kcfveg.fsf@ericabrahamsen.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1517618563 30774 195.159.176.226 (3 Feb 2018 00:42:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Feb 2018 00:42:43 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: =?utf-8?B?5Yav5Lmm?= , Stefan Monnier To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 03 01:42:39 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 1ehluh-0007gl-2U for ged-emacs-devel@m.gmane.org; Sat, 03 Feb 2018 01:42:39 +0100 Original-Received: from localhost ([::1]:46221 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehlwg-0008B5-Ks for ged-emacs-devel@m.gmane.org; Fri, 02 Feb 2018 19:44:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48321) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ehlwU-0008A8-Bg for emacs-devel@gnu.org; Fri, 02 Feb 2018 19:44:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ehlwQ-0002gh-E5 for emacs-devel@gnu.org; Fri, 02 Feb 2018 19:44:30 -0500 Original-Received: from [195.159.176.226] (port=50618 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ehlwQ-0002gH-6I for emacs-devel@gnu.org; Fri, 02 Feb 2018 19:44:26 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1ehltw-00057r-PC for emacs-devel@gnu.org; Sat, 03 Feb 2018 01:41:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 80 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:hDXgsrqK9BgyfeY/pmTMUyclrP8= 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:222457 Archived-At: Stefan Monnier writes: >>> 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. > > Thanks. I played a bit with quail tables in the past, so even though > I don't understand them 100% I should be able to help if needed. By dint of heroic grepping I found the simplest entrypoint to the table: (nth 2 (quail-package "chinese-py")) But this value is already heavily processed in the *wrong* direction (optimized for pinyin-to-character). It's built from the intermediate file "lisp/leim/quail/PY.el", which is produced during `make' from "leim/MISC-DIC/pinyin.map", which is the same source as Feng Shu uses for the pyim package. So the data is accessible in different formats at different stages: build, compile, and load. Now I'm thinking that it might make sense to build the reverse table earlier on -- anyway, I'll explore what's possible there. [...] >>> 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. > > Not at all (actually, back when we got EBDB into elpa.git I mentioned > this possibility). Wish I'd been paying closer attention! >> If it doesn't matter, I can fold this back into ebdb and just use >> `declare-function' with "ext:" to quiet the compiler? > > Yes. > >> In which case, I might as well just do the same for >> `helm-marked-candidates' and leave it as-is? > > Yes. > >> 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. > > I don't have an opinion on counsel-ebdb, but for company-ebdb an even > better option is to turn the company backend into > a completion-at-point-function (so it works not only for company users > but also for old-style TAB-completion users). company primarily does popup-on-a-timer; I think calling it as an explicit completion command (while supported) isn't how it's expected to be used. >> Sorry, I'm just trying to figure out best policy for managing this kind >> of stuff. > > And overall, I really wish someone could sit down, take the ivy, > company, helm, and completion-at-point-function APIs and design a new > API which can be used by all of those UIs so you don't have to implement > N different slight variations of the same thing. But they do their things in such different ways. Some work on a timer with a popup (company), others tie into the existing completion mechanisms (helm and ivy), and others provide their own versions of basic Emacs commands (helm and counsel). How much unification is possible? Eric