* elpa.gnu.org packages requiring external packages @ 2018-01-30 7:22 Glenn Morris 2018-01-30 14:08 ` Richard Stallman 2018-01-30 19:04 ` Glenn Morris 0 siblings, 2 replies; 15+ messages in thread From: Glenn Morris @ 2018-01-30 7:22 UTC (permalink / raw) To: emacs-devel emacs -Q -f list-packages The following packages are listed as "incompatible": ebdb-i18n-chn # needs "pyim" helm-ebdb # needs "helm" org-edna # needs "org 9.0.5" because they depend on packages that are not in GNU elpa (or Emacs). (The last one is an oddity. Apparently the built-in Org isn't recognized as a package?) Is it appropriate for elpa.gnu.org to distribute packages that can't be installed without packages from other repos? (I don't have an opinion, except that it seems odd to have "incompatible" packages show up in the default M-x list-packages output.) ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: elpa.gnu.org packages requiring external packages 2018-01-30 7:22 elpa.gnu.org packages requiring external packages Glenn Morris @ 2018-01-30 14:08 ` Richard Stallman 2018-01-30 14:28 ` Eric Abrahamsen 2018-01-30 19:04 ` Glenn Morris 1 sibling, 1 reply; 15+ messages in thread From: Richard Stallman @ 2018-01-30 14:08 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Is it appropriate for elpa.gnu.org to distribute packages that can't be > installed without packages from other repos? Thanks for reporting this. > ebdb-i18n-chn # needs "pyim" > helm-ebdb # needs "helm" Those should be removed. > org-edna # needs "org 9.0.5" Perhaps that's a bug in the package handling code rather than a problem with that package itself. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: elpa.gnu.org packages requiring external packages 2018-01-30 14:08 ` Richard Stallman @ 2018-01-30 14:28 ` Eric Abrahamsen 2018-01-30 16:13 ` Stefan Monnier 2018-01-31 1:25 ` Richard Stallman 0 siblings, 2 replies; 15+ messages in thread From: Eric Abrahamsen @ 2018-01-30 14:28 UTC (permalink / raw) To: emacs-devel Richard Stallman <rms@gnu.org> writes: > [[[ To any NSA and FBI agents reading my email: please consider ]]] > [[[ whether defending the US Constitution against all enemies, ]]] > [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > Is it appropriate for elpa.gnu.org to distribute packages that can't be > > installed without packages from other repos? > > Thanks for reporting this. > > > ebdb-i18n-chn # needs "pyim" > > helm-ebdb # needs "helm" > > Those should be removed. These two are mine, I can put them in MELPA instead. Eric ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: elpa.gnu.org packages requiring external packages 2018-01-30 14:28 ` Eric Abrahamsen @ 2018-01-30 16:13 ` Stefan Monnier 2018-01-31 17:50 ` Eric Abrahamsen 2018-01-31 1:25 ` Richard Stallman 1 sibling, 1 reply; 15+ messages in thread From: Stefan Monnier @ 2018-01-30 16:13 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-devel >> > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: elpa.gnu.org packages requiring external packages 2018-01-30 16:13 ` Stefan Monnier @ 2018-01-31 17:50 ` Eric Abrahamsen 2018-01-31 23:11 ` Stefan Monnier 2018-02-02 13:49 ` Feng Shu 0 siblings, 2 replies; 15+ messages in thread From: Eric Abrahamsen @ 2018-01-31 17:50 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@IRO.UMontreal.CA> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: elpa.gnu.org packages requiring external packages 2018-01-31 17:50 ` Eric Abrahamsen @ 2018-01-31 23:11 ` Stefan Monnier 2018-02-01 17:54 ` Eric Abrahamsen 2018-02-02 13:49 ` Feng Shu 1 sibling, 1 reply; 15+ messages in thread From: Stefan Monnier @ 2018-01-31 23:11 UTC (permalink / raw) To: emacs-devel >>>> > 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: elpa.gnu.org packages requiring external packages 2018-01-31 23:11 ` Stefan Monnier @ 2018-02-01 17:54 ` Eric Abrahamsen 2018-02-01 19:23 ` Stefan Monnier 0 siblings, 1 reply; 15+ messages in thread From: Eric Abrahamsen @ 2018-02-01 17:54 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> 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). > > 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. I suppose we can defer building it until first usage, etc. >>> 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`. Oh I'm all in favor, but I assumed it would be a no-no from a dependency-graph point of view. If it doesn't matter, I can fold this back into ebdb and just use `declare-function' with "ext:" to quiet the compiler? In which case, I might as well just do the same for `helm-marked-candidates' and leave it as-is? 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. Sorry, I'm just trying to figure out best policy for managing this kind of stuff. >> 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? My observation is that the helm maintainers are not enthusiastic about adding complexity without a good reason, and I would guess this wouldn't count. I've opened an issue, though. Eric ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: elpa.gnu.org packages requiring external packages 2018-02-01 17:54 ` Eric Abrahamsen @ 2018-02-01 19:23 ` Stefan Monnier 2018-02-03 0:43 ` Eric Abrahamsen 0 siblings, 1 reply; 15+ messages in thread From: Stefan Monnier @ 2018-02-01 19:23 UTC (permalink / raw) To: emacs-devel >> 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. > I suppose we can defer building it until first usage, etc. Indeed. >> 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). > 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). > 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. Stefan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: elpa.gnu.org packages requiring external packages 2018-02-01 19:23 ` Stefan Monnier @ 2018-02-03 0:43 ` Eric Abrahamsen 2018-02-04 20:16 ` Dmitry Gutov 0 siblings, 1 reply; 15+ messages in thread From: Eric Abrahamsen @ 2018-02-03 0:43 UTC (permalink / raw) To: emacs-devel; +Cc: 冯书, Stefan Monnier Stefan Monnier <monnier@iro.umontreal.ca> 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: elpa.gnu.org packages requiring external packages 2018-02-03 0:43 ` Eric Abrahamsen @ 2018-02-04 20:16 ` Dmitry Gutov 2018-02-06 19:45 ` Eric Abrahamsen 0 siblings, 1 reply; 15+ messages in thread From: Dmitry Gutov @ 2018-02-04 20:16 UTC (permalink / raw) To: Eric Abrahamsen, emacs-devel Cc: 冯书, Stefan Monnier, Oleh Krehel On 2/3/18 03:43, Eric Abrahamsen wrote: > company primarily does popup-on-a-timer; popup-on-a-timer is irrelevant. company supports completion-at-point-functions via company-capf. The only major feature that completion-at-point-functions don't get (that company backends do) is asynchronous operation. > I think calling it as an > explicit completion command (while supported) isn't how it's expected > to be used. M-x company-<backend> is a well-established way of using it (not the most popular one, of course). >> 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. It would be nice to see some input from Ivy's author: it does support asynchronous operation, and even operating on an incomplete set of results. That's something CAPF does not have yet. Add fuzzy matching, and that's basically everything we want such API to have. > 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? company-capf is an example of one such unification. And given a powerful-enough API, all packages could have the ability, at least, to switch to it. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: elpa.gnu.org packages requiring external packages 2018-02-04 20:16 ` Dmitry Gutov @ 2018-02-06 19:45 ` Eric Abrahamsen 0 siblings, 0 replies; 15+ messages in thread From: Eric Abrahamsen @ 2018-02-06 19:45 UTC (permalink / raw) To: emacs-devel Dmitry Gutov <dgutov@yandex.ru> writes: > On 2/3/18 03:43, Eric Abrahamsen wrote: > >> company primarily does popup-on-a-timer; > > popup-on-a-timer is irrelevant. company supports > completion-at-point-functions via company-capf. > > The only major feature that completion-at-point-functions don't get > (that company backends do) is asynchronous operation. > >> I think calling it as an >> explicit completion command (while supported) isn't how it's expected >> to be used. > > M-x company-<backend> is a well-established way of using it (not the > most popular one, of course). > >>> 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. > > It would be nice to see some input from Ivy's author: it does support > asynchronous operation, and even operating on an incomplete set of > results. That's something CAPF does not have yet. Add fuzzy matching, > and that's basically everything we want such API to have. > >> 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? > > company-capf is an example of one such unification. And given a > powerful-enough API, all packages could have the ability, at least, to > switch to it. I think I came off more skeptical than I meant to here. I really was just curious how this would work. It's not an area of Emacs I've spent much time with (and am not likely to). ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: elpa.gnu.org packages requiring external packages 2018-01-31 17:50 ` Eric Abrahamsen 2018-01-31 23:11 ` Stefan Monnier @ 2018-02-02 13:49 ` Feng Shu 2018-02-02 16:12 ` Stefan Monnier 1 sibling, 1 reply; 15+ messages in thread From: Feng Shu @ 2018-02-02 13:49 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-devel Eric Abrahamsen <eric@ericabrahamsen.net> writes: > Stefan Monnier <monnier@IRO.UMontreal.CA> 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 -- ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: elpa.gnu.org packages requiring external packages 2018-02-02 13:49 ` Feng Shu @ 2018-02-02 16:12 ` Stefan Monnier 0 siblings, 0 replies; 15+ messages in thread From: Stefan Monnier @ 2018-02-02 16:12 UTC (permalink / raw) To: emacs-devel >>>>> > 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. My impression is that it will be simple enough that we could add it to lisp/language/chinese.el or something like that, but indeed distributing it via ELPA would make it easier for other packages to start using it, so we'd have to put it in a separate file. Stefan ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: elpa.gnu.org packages requiring external packages 2018-01-30 14:28 ` Eric Abrahamsen 2018-01-30 16:13 ` Stefan Monnier @ 2018-01-31 1:25 ` Richard Stallman 1 sibling, 0 replies; 15+ messages in thread From: Richard Stallman @ 2018-01-31 1:25 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-devel [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > > ebdb-i18n-chn # needs "pyim" > > > helm-ebdb # needs "helm" > > > > Those should be removed. > These two are mine, I can put them in MELPA instead. Another possible solution is to put pyim and helm into ELPA. Would we want to do that? Do they meet our criteria? -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) Skype: No way! See https://stallman.org/skype.html. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: elpa.gnu.org packages requiring external packages 2018-01-30 7:22 elpa.gnu.org packages requiring external packages Glenn Morris 2018-01-30 14:08 ` Richard Stallman @ 2018-01-30 19:04 ` Glenn Morris 1 sibling, 0 replies; 15+ messages in thread From: Glenn Morris @ 2018-01-30 19:04 UTC (permalink / raw) To: emacs-devel Glenn Morris wrote: > (The last one is an oddity. Apparently the built-in Org isn't > recognized as a package?) Adding a Version: header fixes this. (But I imagine this has been covered before.) --- i/lisp/org/org.el +++ w/lisp/org/org.el @@ -7,6 +7,7 @@ ;; Maintainer: Carsten Dominik <carsten at orgmode dot org> ;; Keywords: outlines, hypermedia, calendar, wp ;; Homepage: http://orgmode.org +;; Version: 9.1.6 ;; ;; This file is part of GNU Emacs. ;; ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2018-02-06 19:45 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-01-30 7:22 elpa.gnu.org packages requiring external packages Glenn Morris 2018-01-30 14:08 ` Richard Stallman 2018-01-30 14:28 ` Eric Abrahamsen 2018-01-30 16:13 ` Stefan Monnier 2018-01-31 17:50 ` Eric Abrahamsen 2018-01-31 23:11 ` Stefan Monnier 2018-02-01 17:54 ` Eric Abrahamsen 2018-02-01 19:23 ` Stefan Monnier 2018-02-03 0:43 ` Eric Abrahamsen 2018-02-04 20:16 ` Dmitry Gutov 2018-02-06 19:45 ` Eric Abrahamsen 2018-02-02 13:49 ` Feng Shu 2018-02-02 16:12 ` Stefan Monnier 2018-01-31 1:25 ` Richard Stallman 2018-01-30 19:04 ` Glenn Morris
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.