* Re: [ELPA] Package proposal: EBDB
@ 2017-08-06 22:12 Roland Winkler
2017-08-07 0:44 ` Eric Abrahamsen
0 siblings, 1 reply; 30+ messages in thread
From: Roland Winkler @ 2017-08-06 22:12 UTC (permalink / raw)
To: emacs-devel; +Cc: jwiegley
> The ability to make BBDB extensible in future without requiring
> core changes is definitely a positive thing.
I agree, using, e.g., country-specific libraries can be a great way
of extending EBDB. But this can also cause problems:
- Writing country-specific libraries for EBDB can be a fair bit of
work. Someone may develop a library for country XYZ up to the
point "it works for me". With the complexity of EBDB the
developer may not notice / not care that some "irrelevant"
features do not work. When other users want to use the library,
they can be stuck.
- Yet worse: "plain" users may have some records from country XYZ in
their database, using the EBDB library for XYZ. At some point,
the very core of the EBDB code base may get updated in a way that
also requires an update of the country-specific EBDB libraries.
But the maintainer of the XYZ library may have disappeared from
the stage for whatever reason. What can the users do? The EBDB
database of a user might become unusable if its XYZ part cannot be
read anymore.
The opposite is also possible: It may turn out that it would be
nice to update the EBDB code base in a way that also requires an
update of the EBDB country-specific "add-on libraries" (or any
other add-on libraries handling certain new fields for EBDB). If
there are many such country-specific add-on libraries out in the
wild, it may become difficult to update the EBDB code base without
breaking EBDB for many users.
(Having developed BBDB for some time, I find it hard to predict
when the code base of BBDB may have reached a level of maturity
that allowed me to exclude the possibility of any further
upgrades, say, in the format of the BBDB database files. Then I
am glad that such updates of BBDB can include the code to migrate
the BBDB database files of the users.)
(BBDB allows the user to customize the handling of addresses in a
country-specific way; but this does not affect what is being
stored in the database file using a universal, country-independent
format.)
- In the worst case, also legal problems may arise: it may not be
possible that someone else updates the code for the XYZ library.
(But I am not a lawyer who could predict the details of such
scenarios.)
I guess that to some extent these are generic aspects of an
object-oriented programming model, which is something I am less
familiar with in such a context. Maybe others can comment.
It is certainly a [EB]BDB-specific issue that any code development
needs to keep in mind that many users already bring along their
database files.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-08-06 22:12 [ELPA] Package proposal: EBDB Roland Winkler @ 2017-08-07 0:44 ` Eric Abrahamsen 0 siblings, 0 replies; 30+ messages in thread From: Eric Abrahamsen @ 2017-08-07 0:44 UTC (permalink / raw) To: emacs-devel "Roland Winkler" <winkler@gnu.org> writes: >> The ability to make BBDB extensible in future without requiring >> core changes is definitely a positive thing. > > I agree, using, e.g., country-specific libraries can be a great way > of extending EBDB. But this can also cause problems: All of these are very valid points. A couple of responses below. > - Writing country-specific libraries for EBDB can be a fair bit of > work. Someone may develop a library for country XYZ up to the > point "it works for me". With the complexity of EBDB the > developer may not notice / not care that some "irrelevant" > features do not work. When other users want to use the library, > they can be stuck. > > - Yet worse: "plain" users may have some records from country XYZ in > their database, using the EBDB library for XYZ. At some point, > the very core of the EBDB code base may get updated in a way that > also requires an update of the country-specific EBDB libraries. > But the maintainer of the XYZ library may have disappeared from > the stage for whatever reason. What can the users do? The EBDB > database of a user might become unusable if its XYZ part cannot be > read anymore. > > The opposite is also possible: It may turn out that it would be > nice to update the EBDB code base in a way that also requires an > update of the EBDB country-specific "add-on libraries" (or any > other add-on libraries handling certain new fields for EBDB). If > there are many such country-specific add-on libraries out in the > wild, it may become difficult to update the EBDB code base without > breaking EBDB for many users. > > (Having developed BBDB for some time, I find it hard to predict > when the code base of BBDB may have reached a level of maturity > that allowed me to exclude the possibility of any further > upgrades, say, in the format of the BBDB database files. Then I > am glad that such updates of BBDB can include the code to migrate > the BBDB database files of the users.) > > (BBDB allows the user to customize the handling of addresses in a > country-specific way; but this does not affect what is being > stored in the database file using a universal, country-independent > format.) EBDB's internationalization framework doesn't alter data structures in any way -- that was a basic principle. It only affects methods that read, parse and display field data. In the (likely) event that a country library gets out of step with the main codebase, errors may occur, but all a user would have to do is unload the problematic library. > - In the worst case, also legal problems may arise: it may not be > possible that someone else updates the code for the XYZ library. > (But I am not a lawyer who could predict the details of such > scenarios.) My idea was to ask that internationalization libraries live in ELPA (I've been talking to Feng Shu, who contributed to the China library, about this issue). The recent copyright discussions on this list have touched on Emacs maintainers' ability to push to ELPA packages when necessary, and I think this is a perfect example. If a country library is suddenly abandoned, someone with ELPA access could do some emergency surgery to at least stop errors. Of course, you can't stop people pushing packages to Melpa, but control is only possible up to a point. The stability of the data structures and API is another question, one I was planning to think about once the number of EBDB users hit the double digits :) > I guess that to some extent these are generic aspects of an > object-oriented programming model, which is something I am less > familiar with in such a context. Maybe others can comment. I've become very, very aware of the pitfalls of [e]lisp's OO model while working on this package. Generic methods are essentially cond branches that don't have to live within the cond statement. That's awesome because cond branches can be defined anywhere. It's a nightmare because... cond branches can be defined anywhere. It's magic, with both the positive and negative implications of "magic". Eric ^ permalink raw reply [flat|nested] 30+ messages in thread
* [ELPA] Package proposal: EBDB @ 2017-07-30 19:18 Eric Abrahamsen 2017-07-31 0:49 ` Richard Stallman ` (2 more replies) 0 siblings, 3 replies; 30+ messages in thread From: Eric Abrahamsen @ 2017-07-30 19:18 UTC (permalink / raw) To: emacs-devel Hi all, I'd like to propose the following package for inclusion in ELPA: https://github.com/girzel/ebdb It's a port/re-write of BBDB using the EIEIO libraries. Perhaps apropos of the recent copyright discussions: there's a fair bit of BBDB code still in there. I haven't gone through and measured, but my top-of-the-head guess is around 15-20%. I've noted this fact in the comments sections of the files, including the names of original authors where applicable. I was trying to be polite, but besides the etiquette question I suppose there might be a copyright issue here. Can anyone advise? I'd be happy to go through and figure out exactly how much (and which parts) of the code is original to BBDB, if that's relevant. My other question is: if I require the cl-generic package for backwards compatibility, what's the earliest Emacs version I can expect to be compatible with? I'm also using seq 2.0 and pcase, and seq at least says it wants Emacs 25.1 or up, so I guess that's my floor, regardless... Thanks, Eric ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-07-30 19:18 Eric Abrahamsen @ 2017-07-31 0:49 ` Richard Stallman 2017-07-31 3:10 ` Eli Zaretskii ` (2 more replies) 2017-08-01 5:33 ` John Wiegley 2017-08-01 5:58 ` Stefan Monnier 2 siblings, 3 replies; 30+ messages in thread From: Richard Stallman @ 2017-07-31 0:49 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. ]]] > Perhaps apropos of the recent copyright discussions: there's a fair > bit of BBDB code still in there. I haven't gone through and measured, > but my top-of-the-head guess is around 15-20%. I've noted this fact in > the comments sections of the files, including the names of original > authors where applicable. Alas, this does raise a copyright issue. To include this in Emacs, we need to get legal papers from all the contributors of code that is still in your version (including you). With the exception of anyone whose contributions to Emacs (including this package) will be minimal (under 10 lines or so). -- Dr Richard Stallman President, Free Software Foundation (gnu.org, fsf.org) Internet Hall-of-Famer (internethalloffame.org) Skype: No way! See stallman.org/skype.html. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-07-31 0:49 ` Richard Stallman @ 2017-07-31 3:10 ` Eli Zaretskii 2017-07-31 3:12 ` Eric Abrahamsen 2017-08-09 21:17 ` Eric Abrahamsen 2 siblings, 0 replies; 30+ messages in thread From: Eli Zaretskii @ 2017-07-31 3:10 UTC (permalink / raw) To: rms; +Cc: eric, emacs-devel > From: Richard Stallman <rms@gnu.org> > Date: Sun, 30 Jul 2017 20:49:56 -0400 > Cc: emacs-devel@gnu.org > > Alas, this does raise a copyright issue. To include this in Emacs, we > need to get legal papers from all the contributors of code that is > still in your version (including you). With the exception of anyone > whose contributions to Emacs (including this package) will be minimal > (under 10 lines or so). Another exceptions is people who already have a copyright assignment on file for Emacs. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-07-31 0:49 ` Richard Stallman 2017-07-31 3:10 ` Eli Zaretskii @ 2017-07-31 3:12 ` Eric Abrahamsen 2017-07-31 3:28 ` Eli Zaretskii 2017-08-09 21:17 ` Eric Abrahamsen 2 siblings, 1 reply; 30+ messages in thread From: Eric Abrahamsen @ 2017-07-31 3:12 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. ]]] > > > Perhaps apropos of the recent copyright discussions: there's a fair > > bit of BBDB code still in there. I haven't gone through and measured, > > but my top-of-the-head guess is around 15-20%. I've noted this fact in > > the comments sections of the files, including the names of original > > authors where applicable. > > Alas, this does raise a copyright issue. To include this in Emacs, we > need to get legal papers from all the contributors of code that is > still in your version (including you). With the exception of anyone > whose contributions to Emacs (including this package) will be minimal > (under 10 lines or so). Okay, I guess that's not a surprise. I'll figure out which code was likely written by whom, and come up with a list of names. If I raise them here, can someone help me check if they've got assignment? As Eli mentions, I bet many of them (including myself) have already signed the papers. Eric ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-07-31 3:12 ` Eric Abrahamsen @ 2017-07-31 3:28 ` Eli Zaretskii 2017-07-31 3:30 ` Eric Abrahamsen 0 siblings, 1 reply; 30+ messages in thread From: Eli Zaretskii @ 2017-07-31 3:28 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-devel > From: Eric Abrahamsen <eric@ericabrahamsen.net> > Date: Sun, 30 Jul 2017 20:12:51 -0700 > > As Eli mentions, I bet many of them (including myself) have already > signed the papers. You can ask me to check about specific names, if you want. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-07-31 3:28 ` Eli Zaretskii @ 2017-07-31 3:30 ` Eric Abrahamsen 0 siblings, 0 replies; 30+ messages in thread From: Eric Abrahamsen @ 2017-07-31 3:30 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Eric Abrahamsen <eric@ericabrahamsen.net> >> Date: Sun, 30 Jul 2017 20:12:51 -0700 >> >> As Eli mentions, I bet many of them (including myself) have already >> signed the papers. > > You can ask me to check about specific names, if you want. Thanks, I'll do that. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-07-31 0:49 ` Richard Stallman 2017-07-31 3:10 ` Eli Zaretskii 2017-07-31 3:12 ` Eric Abrahamsen @ 2017-08-09 21:17 ` Eric Abrahamsen 2017-08-13 1:03 ` Eric Abrahamsen 2 siblings, 1 reply; 30+ messages in thread From: Eric Abrahamsen @ 2017-08-09 21:17 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. ]]] > > > Perhaps apropos of the recent copyright discussions: there's a fair > > bit of BBDB code still in there. I haven't gone through and measured, > > but my top-of-the-head guess is around 15-20%. I've noted this fact in > > the comments sections of the files, including the names of original > > authors where applicable. > > Alas, this does raise a copyright issue. To include this in Emacs, we > need to get legal papers from all the contributors of code that is > still in your version (including you). With the exception of anyone > whose contributions to Emacs (including this package) will be minimal > (under 10 lines or so). Okay, I think I've sorted everything out except for one chunk of one file, where I haven't yet been able to contact the author. I think I might just take that chunk out for now, and get the package moving. Just for background, Roland reminded me of this prior related discussion: https://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01888.html I think I've cleared everything but that one chunk of ebdb-gnus. If that's okay, I'll do a few more compiler-warning cleanups, and add the package as an external. Thanks, Eric ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-08-09 21:17 ` Eric Abrahamsen @ 2017-08-13 1:03 ` Eric Abrahamsen 2017-08-13 21:47 ` Stefan Monnier 0 siblings, 1 reply; 30+ messages in thread From: Eric Abrahamsen @ 2017-08-13 1:03 UTC (permalink / raw) To: emacs-devel Eric Abrahamsen <eric@ericabrahamsen.net> writes: > 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. ]]] >> >> > Perhaps apropos of the recent copyright discussions: there's a fair >> > bit of BBDB code still in there. I haven't gone through and measured, >> > but my top-of-the-head guess is around 15-20%. I've noted this fact in >> > the comments sections of the files, including the names of original >> > authors where applicable. >> >> Alas, this does raise a copyright issue. To include this in Emacs, we >> need to get legal papers from all the contributors of code that is >> still in your version (including you). With the exception of anyone >> whose contributions to Emacs (including this package) will be minimal >> (under 10 lines or so). > > Okay, I think I've sorted everything out except for one chunk of one > file, where I haven't yet been able to contact the author. I think I > might just take that chunk out for now, and get the package moving. Just > for background, Roland reminded me of this prior related discussion: > > https://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01888.html > > I think I've cleared everything but that one chunk of ebdb-gnus. > > If that's okay, I'll do a few more compiler-warning cleanups, and add > the package as an external. Okay, I give up: how do you add an external package? We add the appropriate line to externals-list in the master branch, right? Then push that? Then create a new branch, in my case external/ebdb, and put what in it -- anything? Will something automatically happen if I push that branch to ELPA? Thanks Eric ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-08-13 1:03 ` Eric Abrahamsen @ 2017-08-13 21:47 ` Stefan Monnier 2017-08-14 1:44 ` Eric Abrahamsen 0 siblings, 1 reply; 30+ messages in thread From: Stefan Monnier @ 2017-08-13 21:47 UTC (permalink / raw) To: emacs-devel > We add the appropriate line to externals-list in the master branch, > right? Then push that? Then create a new branch, in my case > external/ebdb, First create (and populate) the externals/ebdb branch. Only once that is done can you update the externals-list file to point to it. > and put what in it -- anything? Pretty much, except: - .el files in the top-level directory. - the metadata in the <pkg>.el file (in your case, ebdb.el). > Will something automatically happen if I push that branch to ELPA? No, it will happen when you push the change to externals-list. Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-08-13 21:47 ` Stefan Monnier @ 2017-08-14 1:44 ` Eric Abrahamsen 2017-08-14 9:45 ` Stefan Monnier 0 siblings, 1 reply; 30+ messages in thread From: Eric Abrahamsen @ 2017-08-14 1:44 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> We add the appropriate line to externals-list in the master branch, >> right? Then push that? Then create a new branch, in my case >> external/ebdb, > > First create (and populate) the externals/ebdb branch. Only once > that is done can you update the externals-list file to point to it. Okay, this is what I was confused about. I have to populate the branch with the code from the existing github repo, obviously I'm not just copying files in there, I need to clone the repo into it somehow. The README says: git clone --reference .. --single-branch --branch externals/PACKAGE $(git config remote.origin.url) PACKAGE Though I can't tell from the README if that's meant to be the command to add an external to ELPA, or just pull down an existing external and look at it. Anyway, running that command just gets me: Could not find remote branch externals/ebdb to clone Which is no surprise. How do I populate the branch? Eric ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-08-14 1:44 ` Eric Abrahamsen @ 2017-08-14 9:45 ` Stefan Monnier 2017-08-14 15:59 ` Eric Abrahamsen 0 siblings, 1 reply; 30+ messages in thread From: Stefan Monnier @ 2017-08-14 9:45 UTC (permalink / raw) To: emacs-devel > Okay, this is what I was confused about. I have to populate the branch > with the code from the existing github repo, obviously I'm not just > copying files in there, I need to clone the repo into it somehow. The > README says: > git clone --reference .. --single-branch --branch externals/PACKAGE $(git > config remote.origin.url) PACKAGE > Though I can't tell from the README if that's meant to be the command to > add an external to ELPA, or just pull down an existing external and look > at it. Anyway, running that command just gets me: "git clone" doesn't modify any existing repository, so that can't be the command that adds a branch to a repository. > How do I populate the branch? IIRC it's something like git push gnuelpa master:externals/ebdb assuming you've configured your local clone of ebdb with something like git remote add gnuelpa <user>@git.sv.gnu.org:/srv/git/emacs/elpa.git -- Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-08-14 9:45 ` Stefan Monnier @ 2017-08-14 15:59 ` Eric Abrahamsen 2017-08-14 23:15 ` Stefan Monnier 0 siblings, 1 reply; 30+ messages in thread From: Eric Abrahamsen @ 2017-08-14 15:59 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1197 bytes --] Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Okay, this is what I was confused about. I have to populate the branch >> with the code from the existing github repo, obviously I'm not just >> copying files in there, I need to clone the repo into it somehow. The >> README says: > >> git clone --reference .. --single-branch --branch externals/PACKAGE $(git >> config remote.origin.url) PACKAGE > >> Though I can't tell from the README if that's meant to be the command to >> add an external to ELPA, or just pull down an existing external and look >> at it. Anyway, running that command just gets me: > > "git clone" doesn't modify any existing repository, so that can't be the > command that adds a branch to a repository. > >> How do I populate the branch? > > IIRC it's something like > > git push gnuelpa master:externals/ebdb > > assuming you've configured your local clone of ebdb with something like > > git remote add gnuelpa <user>@git.sv.gnu.org:/srv/git/emacs/elpa.git Aha! Thank you, that's what I was missing. It seems to have worked, I guess I'll know for sure when the package gets built. Assuming all goes well, can I push this documentation patch to ELPA? Eric [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Add-explicit-instructions-for-new-external-packages.patch --] [-- Type: text/x-diff, Size: 1098 bytes --] From b33289dab83b5f5abe93e4385d322fbfe36a1b27 Mon Sep 17 00:00:00 2001 From: Eric Abrahamsen <eric@ericabrahamsen.net> Date: Mon, 14 Aug 2017 08:56:11 -0700 Subject: [PATCH] Add explicit instructions for new external packages * README: Spell out the process for new external packages. --- README | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/README b/README index 322392997..48c105994 100644 --- a/README +++ b/README @@ -194,6 +194,15 @@ help and only gets in the way. In the `external' case, the copy of the code is not kept here but in the `externals/<pkg-name>' branch in the `elpa' repository. +To add a new externals package, first add this `elpa' repository as a +new remote in your existing repository. Then push a local branch to a +new remote branch in `elpa', named externals/<pkgname>. For example: + + git push elpa master:externals/<pkgname> + +Then edit the `externals-list' file as mentioned above, and push that +change to `elpa's master branch. + You can check out all the external packages into the `packages' directory with the command: -- 2.14.1 ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-08-14 15:59 ` Eric Abrahamsen @ 2017-08-14 23:15 ` Stefan Monnier 2017-08-14 23:50 ` Eric Abrahamsen 0 siblings, 1 reply; 30+ messages in thread From: Stefan Monnier @ 2017-08-14 23:15 UTC (permalink / raw) To: emacs-devel > Aha! Thank you, that's what I was missing. It seems to have worked, I > guess I'll know for sure when the package gets built. I just noticed the following issues: - You use oset-default on instance fields. This used to work in earlier EIEIO and still mostly work now thanks to a hack, but it creates a weird/adhoc semantics in terms of interaction with the :initform, so I'd like to get rid of this backward compatibility. - ebdb-vm and ebdb-mu4e will break the compilation of the package if the user doesn't have VM and mu4e installed. The appended patch tries to fix those two, but please take a look at it to make sure it still works correctly (especially the ebdb-vm part is quick&dirty, leaving a lot of warnings when VM is not installed, some of them may be real bugs). > Assuming all goes well, can I push this documentation patch to ELPA? Yes, please do, thank you, Stefan diff --git a/.gitignore b/.gitignore new file mode 100644 index 000000000..f56da6eb7 --- /dev/null +++ b/.gitignore @@ -0,0 +1,4 @@ +*.elc +ebdb-autoloads.el +ebdb-pkg.el + diff --git a/ebdb-format.el b/ebdb-format.el index cd8ccc5ae..46726e15f 100644 --- a/ebdb-format.el +++ b/ebdb-format.el @@ -40,7 +40,8 @@ (coding-system :type symbol :initarg :coding-system - :initform nil + ;; "`," is used to trick EIEIO into evaluating the form. + :initform `,buffer-file-coding-system :documentation "The coding system for the formatted file/buffer/stream.") ;; TODO: Provide for "psuedo field classes" like 'primary-mail and @@ -93,8 +94,6 @@ :documentation "Abstract base class for EBDB formatters. Subclass this to produce real formatters.") -(eieio-oset-default 'ebdb-formatter 'coding-system buffer-file-coding-system) - (cl-defmethod ebdb-string ((fmt ebdb-formatter)) (slot-value fmt 'object-name)) diff --git a/ebdb-mu4e.el b/ebdb-mu4e.el index 2e4ee5e20..8d0798391 100644 --- a/ebdb-mu4e.el +++ b/ebdb-mu4e.el @@ -25,9 +25,11 @@ ;;; Code: (require 'ebdb-mua) -(require 'mu4e-view) +(if t (require 'mu4e-view)) ;;Dummy test to `require' only at runtime. ;; Tackle `mu4e-headers-mode' later +(defvar mu4e~view-buffer-name) +(defvar mu4e-view-mode-map) (cl-defmethod ebdb-mua-message-header ((header string) &context (major-mode mu4e-view-mode)) @@ -45,7 +47,7 @@ ;; Why wasn't `ebdb-mua-auto-update' ever hooked in to mu4e? -(add-hook 'mu4e-main-mode-hook 'ebdb-insinuate-mu4e) +(add-hook 'mu4e-main-mode-hook #'ebdb-insinuate-mu4e) (provide 'ebdb-mu4e) ;;; ebdb-mu4e.el ends here diff --git a/ebdb-vm.el b/ebdb-vm.el index 27f5f4c69..00766e10b 100644 --- a/ebdb-vm.el +++ b/ebdb-vm.el @@ -25,6 +25,7 @@ (require 'ebdb-com) (require 'ebdb-mua) +(when t ;;Dummy test to `require' only at runtime. (require 'vm-autoloads) (require 'vm) (require 'vm-motion) @@ -33,7 +34,7 @@ (require 'vm-vars) (require 'vm-macro) (require 'vm-message) -(require 'vm-misc) +(require 'vm-misc)) (defgroup ebdb-mua-vm nil "VM-specific EBDB customizations" @@ -366,9 +367,11 @@ from different senders." ;; the EBDB record of the sender. (lambda (m) (ebdb-mua-summary-mark (vm-su-from m)))))) +;; FIXME: `vm' is required earlier, so (eval-after-load "vm" ...) doesn't make +;; much sense at this point. (eval-after-load "vm" '(ebdb-insinuate-vm)) -(add-hook 'vm-select-message-hook 'ebdb-mua-auto-update) +(add-hook 'vm-select-message-hook #'ebdb-mua-auto-update) (provide 'ebdb-vm) ;;; ebdb-vm.el ends here diff --git a/ebdb.el b/ebdb.el index 16af67494..1daaf8623 100644 --- a/ebdb.el +++ b/ebdb.el @@ -2056,11 +2056,11 @@ Eventually this method will go away." (defclass ebdb-field-image (ebdb-field) ((image :type (or null string symbol) - :initarg :image)) + :initarg :image + ;; "`," is used to trick EIEIO into evaluating the form. + :initform `,ebdb-image)) :human-readable "image") -(eieio-oset-default 'ebdb-field-image 'image ebdb-image) - (cl-defmethod ebdb-read ((image (subclass ebdb-field-image)) &optional slots obj) (let ((existing (when obj (slot-value obj 'image))) value) @@ -3378,7 +3378,8 @@ executable. When a symbol, assume an Elisp function." ;; I don't think I can actually set this to `ebdb-record': the ;; type needs to be a class, not an instance. Can I do that? :type symbol - :initform nil + ;; "`," is used to trick EIEIO into evaluating the form. + :initform `,ebdb-default-record-class :custom symbol :documentation "The default EIEIO class for records in this database. Must @@ -3389,11 +3390,6 @@ not be instantiated directly, subclass it instead." :allow-nil-initform t :abstract t) -;; I was told not to use this in Gnus, but I don't remember why. I -;; suspect it was backward compatibility, and that's obviously already -;; out the window. -(oset-default 'ebdb-db record-class ebdb-default-record-class) - (cl-defmethod initialize-instance ((db ebdb-db) &optional slots) "Make sure DB has a uuid." (unless (and (slot-boundp db 'uuid) ^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-08-14 23:15 ` Stefan Monnier @ 2017-08-14 23:50 ` Eric Abrahamsen 2017-08-15 7:49 ` Stefan Monnier 0 siblings, 1 reply; 30+ messages in thread From: Eric Abrahamsen @ 2017-08-14 23:50 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Aha! Thank you, that's what I was missing. It seems to have worked, I >> guess I'll know for sure when the package gets built. > > I just noticed the following issues: > - You use oset-default on instance fields. This used to work in earlier > EIEIO and still mostly work now thanks to a hack, but it creates > a weird/adhoc semantics in terms of interaction with the :initform, so > I'd like to get rid of this backward compatibility. Huh, interesting. Is that function completely deprecated, or still usable for class-allocated slots? > - ebdb-vm and ebdb-mu4e will break the compilation of the package if the > user doesn't have VM and mu4e installed. > > The appended patch tries to fix those two, but please take a look at it > to make sure it still works correctly (especially the ebdb-vm part is > quick&dirty, leaving a lot of warnings when VM is not installed, some > of them may be real bugs). I thought about extracting those two into separate packages, and probably should have done that. I pulled all the other libraries that depended on non-core packages into their own separate packages, and I don't know why I didn't do that for these two. Actually, I do know: vm and mu4e aren't installable via the package manager. If I make separate packages, and put a package-requires header in them for vm and mu4e, will package.el be satisfied if a user has installed them via other means? Or will it bark? Another option would be a boatload of (autoload 'function "ext:vm") statements. I'll make your other changes, and maybe just pull ebdb-vm and ebdb-mu4e for now, pending further thought. >> Assuming all goes well, can I push this documentation patch to ELPA? > > Yes, please do, thank you, Will do. Thanks, Eric ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-08-14 23:50 ` Eric Abrahamsen @ 2017-08-15 7:49 ` Stefan Monnier 2017-08-15 15:30 ` Eric Abrahamsen 0 siblings, 1 reply; 30+ messages in thread From: Stefan Monnier @ 2017-08-15 7:49 UTC (permalink / raw) To: emacs-devel > Huh, interesting. Is that function completely deprecated, or still > usable for class-allocated slots? It's fine for class-allocated slots. >> - ebdb-vm and ebdb-mu4e will break the compilation of the package if the >> user doesn't have VM and mu4e installed. >> The appended patch tries to fix those two, but please take a look at it >> to make sure it still works correctly (especially the ebdb-vm part is >> quick&dirty, leaving a lot of warnings when VM is not installed, some >> of them may be real bugs). > I thought about extracting those two into separate packages, and > probably should have done that. That's one way to solve the problem, but it's not necessary. > Actually, I do know: vm and mu4e aren't installable via the package > manager. If I make separate packages, and put a package-requires header > in them for vm and mu4e, will package.el be satisfied if a user has > installed them via other means? Or will it bark? It will bark :-( > Another option would be a boatload of (autoload 'function "ext:vm") > statements. For ebdb-mu4e, I think the patch I send leads to correct results, so I think it's an acceptable solution. For VM, I'm not sure if the result is correct. It basically depends on whether part of the VM code are needed during compilation (most common case is if your code uses VM macros). Fixing the warnings is easy enough (rather than autoloads, you can use `declare-function`). Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-08-15 7:49 ` Stefan Monnier @ 2017-08-15 15:30 ` Eric Abrahamsen 2017-08-17 16:57 ` Eric Abrahamsen 0 siblings, 1 reply; 30+ messages in thread From: Eric Abrahamsen @ 2017-08-15 15:30 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Huh, interesting. Is that function completely deprecated, or still >> usable for class-allocated slots? > > It's fine for class-allocated slots. > >>> - ebdb-vm and ebdb-mu4e will break the compilation of the package if the >>> user doesn't have VM and mu4e installed. >>> The appended patch tries to fix those two, but please take a look at it >>> to make sure it still works correctly (especially the ebdb-vm part is >>> quick&dirty, leaving a lot of warnings when VM is not installed, some >>> of them may be real bugs). >> I thought about extracting those two into separate packages, and >> probably should have done that. > > That's one way to solve the problem, but it's not necessary. > >> Actually, I do know: vm and mu4e aren't installable via the package >> manager. If I make separate packages, and put a package-requires header >> in them for vm and mu4e, will package.el be satisfied if a user has >> installed them via other means? Or will it bark? > > It will bark :-( > >> Another option would be a boatload of (autoload 'function "ext:vm") >> statements. > > For ebdb-mu4e, I think the patch I send leads to correct results, so > I think it's an acceptable solution. > > For VM, I'm not sure if the result is correct. It basically depends on > whether part of the VM code are needed during compilation (most common > case is if your code uses VM macros). > > Fixing the warnings is easy enough (rather than autoloads, you can use > `declare-function`). Okay, I'll apply your solution to ebdb-mu4e, then take a closer look at vm. Thanks, Eric ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-08-15 15:30 ` Eric Abrahamsen @ 2017-08-17 16:57 ` Eric Abrahamsen 2017-08-17 22:21 ` Stefan Monnier 0 siblings, 1 reply; 30+ messages in thread From: Eric Abrahamsen @ 2017-08-17 16:57 UTC (permalink / raw) To: emacs-devel Eric Abrahamsen <eric@ericabrahamsen.net> writes: > Stefan Monnier <monnier@iro.umontreal.ca> writes: > [...] >> For VM, I'm not sure if the result is correct. It basically depends on >> whether part of the VM code are needed during compilation (most common >> case is if your code uses VM macros). >> >> Fixing the warnings is easy enough (rather than autoloads, you can use >> `declare-function`). > > Okay, I'll apply your solution to ebdb-mu4e, then take a closer look at > vm. Turns out it's a moot point, as VM only supports Emacs up to 23, two major modes less than what EBDB requires. Before I found that out I did get the compiler to keep quiet, at the cost of I think just one defsubst that the compiler would never inline. Oh well, Eric ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-08-17 16:57 ` Eric Abrahamsen @ 2017-08-17 22:21 ` Stefan Monnier 2017-08-17 22:52 ` Eric Abrahamsen 0 siblings, 1 reply; 30+ messages in thread From: Stefan Monnier @ 2017-08-17 22:21 UTC (permalink / raw) To: emacs-devel > Turns out it's a moot point, as VM only supports Emacs up to 23, two > major modes less than what EBDB requires. It's probably easy to make it work with Emacs≥24, tho. > Before I found that out I did get the compiler to keep quiet, at the > cost of I think just one defsubst that the compiler would > never inline. Good, thanks, Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-08-17 22:21 ` Stefan Monnier @ 2017-08-17 22:52 ` Eric Abrahamsen 2017-08-17 23:27 ` Stefan Monnier 0 siblings, 1 reply; 30+ messages in thread From: Eric Abrahamsen @ 2017-08-17 22:52 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Turns out it's a moot point, as VM only supports Emacs up to 23, two >> major modes less than what EBDB requires. Major *version numbers*. > It's probably easy to make it work with Emacs≥24, tho. Sorry, do you mean VM or EBDB? VM is out of my hands... I ran "make", it bailed when it couldn't find Emacs 23, and I gave up there. EBDB currently uses seq, which requires Emacs 25. I could remove that dependency, but I sure like seq. Pcase is Emacs 24, and I don't think I'm willing to give up pcase. Eric ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-08-17 22:52 ` Eric Abrahamsen @ 2017-08-17 23:27 ` Stefan Monnier 2017-08-17 23:31 ` Eric Abrahamsen 0 siblings, 1 reply; 30+ messages in thread From: Stefan Monnier @ 2017-08-17 23:27 UTC (permalink / raw) To: emacs-devel >> It's probably easy to make it work with Emacs≥24, tho. > Sorry, do you mean VM or EBDB? I mean VM. > VM is out of my hands... I know. I just mean that that the work you did on ebdb-vm is not necessarily wasted, because it'll probably not take much time from someone motivated to make VM work on Emacs-25, so it'll likely happen at some point. > EBDB currently uses seq, which requires Emacs 25. I could remove that > dependency, but I sure like seq. Pcase is Emacs 24, and I don't think > I'm willing to give up pcase. I think it'll be easier (and preferable) to move VM up to Emacs-25 ;-) So we can just wait, Stefan ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-08-17 23:27 ` Stefan Monnier @ 2017-08-17 23:31 ` Eric Abrahamsen 0 siblings, 0 replies; 30+ messages in thread From: Eric Abrahamsen @ 2017-08-17 23:31 UTC (permalink / raw) To: emacs-devel Stefan Monnier <monnier@iro.umontreal.ca> writes: >>> It's probably easy to make it work with Emacs≥24, tho. >> Sorry, do you mean VM or EBDB? > > I mean VM. > >> VM is out of my hands... > > I know. I just mean that that the work you did on ebdb-vm is not > necessarily wasted, because it'll probably not take much time from > someone motivated to make VM work on Emacs-25, so it'll likely happen at > some point. Gotcha. They have a fairly active ML, I'll poke a little bit. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-07-30 19:18 Eric Abrahamsen 2017-07-31 0:49 ` Richard Stallman @ 2017-08-01 5:33 ` John Wiegley 2017-08-01 16:04 ` Eric Abrahamsen 2017-08-01 5:58 ` Stefan Monnier 2 siblings, 1 reply; 30+ messages in thread From: John Wiegley @ 2017-08-01 5:33 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-devel >>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes: EA> It's a port/re-write of BBDB using the EIEIO libraries. Can you explain the benefit of including this work into Emacs? Specifically, does it solve problems being encountered with the current BBDB, or does it pave the way for new work? Thanks, -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-08-01 5:33 ` John Wiegley @ 2017-08-01 16:04 ` Eric Abrahamsen 2017-08-01 22:25 ` John Wiegley 0 siblings, 1 reply; 30+ messages in thread From: Eric Abrahamsen @ 2017-08-01 16:04 UTC (permalink / raw) To: emacs-devel John Wiegley <jwiegley@gmail.com> writes: >>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes: > > EA> It's a port/re-write of BBDB using the EIEIO libraries. > > Can you explain the benefit of including this work into Emacs? Specifically, > does it solve problems being encountered with the current BBDB, or does it > pave the way for new work? It was originally meant to be a set of patches to BBDB, but snowballed from there. My feeling was that the original package was inflexible, and very difficult to extend. EBDB is made to be extensible: multiple databases, an internationalization mechanism, hooks for integration into other packages, subclassable records and fields that can have arbitrary behavior... The code as it stands offers a few solid benefits over BBDB, but most importantly there's a lot of room for building on top of it. The class/generic method approach means that other packages could add all kinds of new behavior to EBDB simply by being loaded. Probably some of it did end up being new code for new code's sake... I wasn't thinking of ELPA as "inclusion into Emacs", but maybe that's what it is? Stefan Monnier <monnier@iro.umontreal.ca> writes: >> It's a port/re-write of BBDB using the EIEIO libraries. >> Perhaps apropos of the recent copyright discussions: there's a fair >> bit of BBDB code still in there. > > BTW, which BBDB are we talking about, here. > Is it the BBDB v2, or BBDB v3? > > > Stefan "presuming v3" Yup, I started out with version 3. Eric ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-08-01 16:04 ` Eric Abrahamsen @ 2017-08-01 22:25 ` John Wiegley 2017-08-01 23:52 ` Eric Abrahamsen 0 siblings, 1 reply; 30+ messages in thread From: John Wiegley @ 2017-08-01 22:25 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-devel >>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes: EA> I wasn't thinking of ELPA as "inclusion into Emacs", but maybe that's what EA> it is? Yes, that's what certainly it's intended to be/mean, from my point of view. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-08-01 22:25 ` John Wiegley @ 2017-08-01 23:52 ` Eric Abrahamsen 2017-08-02 1:28 ` John Wiegley 0 siblings, 1 reply; 30+ messages in thread From: Eric Abrahamsen @ 2017-08-01 23:52 UTC (permalink / raw) To: emacs-devel John Wiegley <jwiegley@gmail.com> writes: >>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes: > > EA> I wasn't thinking of ELPA as "inclusion into Emacs", but maybe that's what > EA> it is? > > Yes, that's what certainly it's intended to be/mean, from my point of view. Good to know. I guess my arguments for the package are pretty much what I stated earlier, then. The present BBDB is limited in that record fields are just key-value pairs, for the most part strings. If you want to add a new type of field, you need to add branches to about a dozen `cond' statements throughout the BBDB codebase. In EBDB, new field types can be added via an external library. Likewise, the behavior of existing fields (and records and databases) can be altered with external libraries. EBDB fields can have arbitrarily complex data slots and behavior. Records can be of different types. People and organizations are built in, other record types can be added. Databases are likewise subclass-able. I think EBDB's internationalization framework is important. BBDB is fairly US-centric. EBDB can provide very fine-grained behavior for phones, addresses and names from various countries/locales/scripts. I have so far only scratched my own itch, with a China-specific library, but all the hooks are there. At present EBDB has some advantages (like multiple databases, record UUIDs, multiple buffers) that could be added to BBDB as well. But I think the points above are things that could not be reasonably added to BBDB as it stands: that was the point of the rewrite. Eric ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-08-01 23:52 ` Eric Abrahamsen @ 2017-08-02 1:28 ` John Wiegley 2017-08-02 3:08 ` Eric Abrahamsen 0 siblings, 1 reply; 30+ messages in thread From: John Wiegley @ 2017-08-02 1:28 UTC (permalink / raw) To: Eric Abrahamsen; +Cc: emacs-devel >>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes: EA> I guess my arguments for the package are pretty much what I stated EA> earlier, then. The present BBDB is limited in that record fields are just EA> key-value pairs, for the most part strings. If you want to add a new type EA> of field, you need to add branches to about a dozen `cond' statements EA> throughout the BBDB codebase. In EBDB, new field types can be added via an EA> external library. Likewise, the behavior of existing fields (and records EA> and databases) can be altered with external libraries. EBDB fields can EA> have arbitrarily complex data slots and behavior. This paragraph is enough for me to want it. :) The ability to make BBDB extensible in future without requiring core changes is definitely a positive thing. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-08-02 1:28 ` John Wiegley @ 2017-08-02 3:08 ` Eric Abrahamsen 0 siblings, 0 replies; 30+ messages in thread From: Eric Abrahamsen @ 2017-08-02 3:08 UTC (permalink / raw) To: emacs-devel John Wiegley <jwiegley@gmail.com> writes: >>>>>> "EA" == Eric Abrahamsen <eric@ericabrahamsen.net> writes: > > EA> I guess my arguments for the package are pretty much what I stated > EA> earlier, then. The present BBDB is limited in that record fields are just > EA> key-value pairs, for the most part strings. If you want to add a new type > EA> of field, you need to add branches to about a dozen `cond' statements > EA> throughout the BBDB codebase. In EBDB, new field types can be added via an > EA> external library. Likewise, the behavior of existing fields (and records > EA> and databases) can be altered with external libraries. EBDB fields can > EA> have arbitrarily complex data slots and behavior. > > This paragraph is enough for me to want it. :) The ability to make BBDB > extensible in future without requiring core changes is definitely a positive > thing. Well, good! I'm bad at pitching, but I wouldn't have put all this work in if I didn't think it was a fundamental improvement. The goal is a fairly tight core of code that doesn't need to know about the particulars of various database, record and field classes. I'll continue sorting out the copyright questions. Thanks, Eric ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [ELPA] Package proposal: EBDB 2017-07-30 19:18 Eric Abrahamsen 2017-07-31 0:49 ` Richard Stallman 2017-08-01 5:33 ` John Wiegley @ 2017-08-01 5:58 ` Stefan Monnier 2 siblings, 0 replies; 30+ messages in thread From: Stefan Monnier @ 2017-08-01 5:58 UTC (permalink / raw) To: emacs-devel > It's a port/re-write of BBDB using the EIEIO libraries. > Perhaps apropos of the recent copyright discussions: there's a fair > bit of BBDB code still in there. BTW, which BBDB are we talking about, here. Is it the BBDB v2, or BBDB v3? Stefan "presuming v3" ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2017-08-17 23:31 UTC | newest] Thread overview: 30+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-08-06 22:12 [ELPA] Package proposal: EBDB Roland Winkler 2017-08-07 0:44 ` Eric Abrahamsen -- strict thread matches above, loose matches on Subject: below -- 2017-07-30 19:18 Eric Abrahamsen 2017-07-31 0:49 ` Richard Stallman 2017-07-31 3:10 ` Eli Zaretskii 2017-07-31 3:12 ` Eric Abrahamsen 2017-07-31 3:28 ` Eli Zaretskii 2017-07-31 3:30 ` Eric Abrahamsen 2017-08-09 21:17 ` Eric Abrahamsen 2017-08-13 1:03 ` Eric Abrahamsen 2017-08-13 21:47 ` Stefan Monnier 2017-08-14 1:44 ` Eric Abrahamsen 2017-08-14 9:45 ` Stefan Monnier 2017-08-14 15:59 ` Eric Abrahamsen 2017-08-14 23:15 ` Stefan Monnier 2017-08-14 23:50 ` Eric Abrahamsen 2017-08-15 7:49 ` Stefan Monnier 2017-08-15 15:30 ` Eric Abrahamsen 2017-08-17 16:57 ` Eric Abrahamsen 2017-08-17 22:21 ` Stefan Monnier 2017-08-17 22:52 ` Eric Abrahamsen 2017-08-17 23:27 ` Stefan Monnier 2017-08-17 23:31 ` Eric Abrahamsen 2017-08-01 5:33 ` John Wiegley 2017-08-01 16:04 ` Eric Abrahamsen 2017-08-01 22:25 ` John Wiegley 2017-08-01 23:52 ` Eric Abrahamsen 2017-08-02 1:28 ` John Wiegley 2017-08-02 3:08 ` Eric Abrahamsen 2017-08-01 5:58 ` Stefan Monnier
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.