persistent storage for Emacs packages

persistent storage for Emacs packages

[Tyler Smith]

[-- Attachment #1: Type: text/plain, Size: 683 bytes --]

Hello,

I am developing a small Emacs extension I would like to distribute as a
package. This package provides an interface to the GRASS gis software.
During initialization, a table of completions is generated. This takes
several minutes, but only needs to be done once. Where should I be saving
this data?

I'm currently using customize-save-variable, but as users aren't expected
to modify the values directly this is not correct. Is there a location I
can count on having read and write access to across platforms? Or should I
be requiring each user to specify the location of the data file as a
customization option?

I would appreciate any suggestions.

Thank you,

Tyler Smith

[-- Attachment #2: Type: text/html, Size: 885 bytes --]

Re: persistent storage for Emacs packages

[Thorsten Jolitz]

Tyler Smith <tyler.smith@mail.mcgill.ca> writes:

> I am developing a small Emacs extension I would like to distribute as a
> package. This package provides an interface to the GRASS gis software. 

This is VERY interesting, please announce when you are ready. I always
thought it would be great to have GRASS GIS as an Org-Babel "language",
since Org-mode with its R support and active document characteristics
would make a perfect environment for producing (dynamic) GIS reports. 

(Even if the existing Org Babel support for Shell would suffice to
control GRASS from Org-mode source-blocks, a specialized and convenient
interface would be better). 

-- 
cheers,
Thorsten

Re: persistent storage for Emacs packages

[Stefan Monnier]

> several minutes, but only needs to be done once. Where should I be saving
> this data?

How 'bout ~/.emacs.d/grass-data ?


        Stefan

Re: persistent storage for Emacs packages

[Tyler Smith]

[-- Attachment #1: Type: text/plain, Size: 382 bytes --]

That would do. Is ~/.emacs.d/ guaranteed to be present? What happens if a
user is using ~/.emacs instead of ~/.emacs.d/init.el?

Thanks,

Tyler


On Fri, Oct 18, 2013 at 3:54 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> > several minutes, but only needs to be done once. Where should I be saving
> > this data?
>
> How 'bout ~/.emacs.d/grass-data ?
>
>
>         Stefan
>

[-- Attachment #2: Type: text/html, Size: 827 bytes --]

Re: persistent storage for Emacs packages

[Josh]

On Fri, Oct 18, 2013 at 12:54 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> several minutes, but only needs to be done once. Where should I be saving
>> this data?
>
> How 'bout ~/.emacs.d/grass-data ?

I think you mean (expand-file-name "grass-data" user-emacs-directory)
or similar.

Re: persistent storage for Emacs packages

[Karl Fogel]

Tyler Smith <tyler.smith@mail.mcgill.ca> writes:
>I am developing a small Emacs extension I would like to distribute as a
>package. This package provides an interface to the GRASS gis software.
>During initialization, a table of completions is generated. This takes
>several minutes, but only needs to be done once. Where should I be saving
>this data?
>
>I'm currently using customize-save-variable, but as users aren't expected
>to modify the values directly this is not correct. Is there a location I
>can count on having read and write access to across platforms? Or should I
>be requiring each user to specify the location of the data file as a
>customization option?
>
>I would appreciate any suggestions.

I had a similar need, and developed a system for generic persistent
storage from Emacs.  It lives only in my .emacs right now, but that is
online and freely licensed here:

  http://svn.red-bean.com/repos/kfogel/trunk/.emacs

Look at the functions named `kf-persist-*' and comments therearound.

If it looks useful to you, I'd be fine with moving it out of my .emacs
and having it packaged in some more normal way.

Best,
-Karl

Re: persistent storage for Emacs packages

[Nic Ferrier]

> I had a similar need, and developed a system for generic persistent
> storage from Emacs.  It lives only in my .emacs right now, but that is
> online and freely licensed here:
>
>   http://svn.red-bean.com/repos/kfogel/trunk/.emacs
>
> Look at the functions named `kf-persist-*' and comments therearound.
>
> If it looks useful to you, I'd be fine with moving it out of my .emacs
> and having it packaged in some more normal way.

I have also written emacs-db:

  https://github.com/nicferrier/emacs-db 

which offers persistent hashtables basically... there is also a postgres
backend using pg.el.



Nic

Re: persistent storage for Emacs packages

[Rüdiger Sonderfeld]

On Friday 18 October 2013 15:37:19 Josh wrote:
> On Fri, Oct 18, 2013 at 12:54 PM, Stefan Monnier
> 
> <monnier@iro.umontreal.ca> wrote:
> >> several minutes, but only needs to be done once. Where should I be saving
> >> this data?
> > 
> > How 'bout ~/.emacs.d/grass-data ?
> 
> I think you mean (expand-file-name "grass-data" user-emacs-directory)
> or similar.

I think (locate-user-emacs-file "grass-data") would be better.

Something like

(defcustom grass-data-file (locate-user-emacs-file "grass-data")
  :type 'file
  :group 'grass)

Regards,
Rüdiger

Re: persistent storage for Emacs packages

[Josh]

On Fri, Oct 18, 2013 at 3:49 PM, Rüdiger Sonderfeld
<ruediger@c-plusplus.de> wrote:
> On Friday 18 October 2013 15:37:19 Josh wrote:
>> I think you mean (expand-file-name "grass-data" user-emacs-directory)
>> or similar.
>
> I think (locate-user-emacs-file "grass-data") would be better.

Indeed it would.  The form I suggested was adapted from the first grep
result that caught my eye:
  ./net/eww.el:  (with-temp-file (expand-file-name "eww-bookmarks"
user-emacs-directory)
but I see that I stopped reading too soon :)

Re: persistent storage for Emacs packages

[Tyler Smith]

[-- Attachment #1: Type: text/plain, Size: 821 bytes --]

Thanks!

Following up on your suggestions, I found the appropriate part of TFM:

https://www.gnu.org/software/emacs/manual/html_node/elisp/Standard-File-Names.html#Standard-File-Names

Tyler
On Oct 18, 2013 7:02 PM, "Josh" <josh@foxtail.org> wrote:

> On Fri, Oct 18, 2013 at 3:49 PM, Rüdiger Sonderfeld
> <ruediger@c-plusplus.de> wrote:
> > On Friday 18 October 2013 15:37:19 Josh wrote:
> >> I think you mean (expand-file-name "grass-data" user-emacs-directory)
> >> or similar.
> >
> > I think (locate-user-emacs-file "grass-data") would be better.
>
> Indeed it would.  The form I suggested was adapted from the first grep
> result that caught my eye:
>   ./net/eww.el:  (with-temp-file (expand-file-name "eww-bookmarks"
> user-emacs-directory)
> but I see that I stopped reading too soon :)
>

[-- Attachment #2: Type: text/html, Size: 1310 bytes --]

Re: persistent storage for Emacs packages

[Stefan Monnier]

> That would do. Is ~/.emacs.d/ guaranteed to be present?

No.

> What happens if a user is using ~/.emacs instead of ~/.emacs.d/init.el?

Nothing in particular.  The ~/.emacs.d directory may still exist, or not.
So you may have to create the directory.


        Stefan

Emacs and XDG Base Dir Spec was: persistent storage for Emacs packages

[Thomas Koch]

There is a "standard" where to place different kind of files inside a users home 
directory[1], in short:

config: ~/.config/$APPNAME/
cache: ~/.cache/$APPNAME/
data: ~/.local/share/$APPNAME/

Unfortunately the standard does not yet include a place for STATE data[2].

It would be nice, if emacs would also use this "standard". This would make it 
much nicer to keep the emacs config in version control without an elaborate 
ignore file. Some people like me also keep their ~/.cache in a ramdisk[3].

[1] http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
[2] https://wiki.debian.org/XDGBaseDirectorySpecification#state
[3] https://github.com/xtaran/unburden-home-dir

Re: Emacs and XDG Base Dir Spec was: persistent storage for Emacs packages

[Glenn Morris]

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=583

Re: Emacs and XDG Base Dir Spec was: persistent storage for Emacs packages

[Jan Djärv]

Hello.

The freedesktop standards tend to come and go and change quite a bit.
Are we contemplating this "standard" for non-freedesktop systems also?

	Jan D.

21 okt 2013 kl. 01:16 skrev Glenn Morris <rgm@gnu.org>:

> 
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=583

Re: Emacs and XDG Base Dir Spec was: persistent storage for Emacs packages

[Glenn Morris]

Jan Djärv wrote:

> The freedesktop standards tend to come and go and change quite a bit.

Really? No stable state reached after 5 years?

> Are we contemplating this "standard" for non-freedesktop systems also?

Noboby shows any sign of actually _doing_ anything, so I wouldn't worry.

> 21 okt 2013 kl. 01:16 skrev Glenn Morris <rgm@gnu.org>:
>> 
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=583

Re: Emacs and XDG Base Dir Spec was: persistent storage for Emacs packages

[Thien-Thi Nguyen]

[-- Attachment #1: Type: text/plain, Size: 656 bytes --]

() Glenn Morris <rgm@gnu.org>
() Mon, 21 Oct 2013 02:32:37 -0400

   Noboby shows any sign of actually _doing_ anything, so I wouldn't worry.

FWIW, the xdgdirs program:

 http://www.gnuvola.org/software/xdgdirs/

outputs Emacs-‘read’able alists by consulting the specified env vars.
It's used (if found at runtime) by GNU Alive, currently, and will be
likewise used by GNU Serveez starting w/ the next release.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Emacs and XDG Base Dir Spec was: persistent storage for Emacs packages

[Jan Djärv]

Hello. 

> 21 okt 2013 kl. 08:32 skrev Glenn Morris <rgm@gnu.org>:
> 
> Jan Djärv wrote:
> 
>> The freedesktop standards tend to come and go and change quite a bit.
> 
> Really? No stable state reached after 5 years?
> 

The latest version is about 3 years old.  That is pretty stable for a freedesktop specifikation. But this spec. is about one page long...

>> Are we contemplating this "standard" for non-freedesktop systems also?
> 
> Noboby shows any sign of actually _doing_ anything, so I wouldn't worry.

It would be good to know what the policy is in case someone would like to do something. OSX-style dirs on OSX, W32-style on W32, XDG-style on Freedesktop systems (how can we know that?), old style for the rest?

     Jan D. 

> 
>>> 21 okt 2013 kl. 01:16 skrev Glenn Morris <rgm@gnu.org>:
>>> 
>>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=583

Re: Emacs and XDG Base Dir Spec was: persistent storage for Emacs packages

[Stefan Monnier]

> The freedesktop standards tend to come and go and change quite a bit.
> Are we contemplating this "standard" for non-freedesktop systems also?

We could work our way slowly in that direction.

Currently ~/.emacs.d is pretty messy, so it might be good to try and
"clean it up", and along the way, we could try and integrate some of
XDG's suggestions.  Not sure how much of XDG would be useful, tho.

E.g. we could start with a ~/.emacs.d/cache/ directory where all the
files that can be reconstructed would go.  Tho there aren't many such
files, IIRC.

But w.r.t "config vs data" this distinction is far from clear.

Still, we have the problem with ~/.emacs.d that many users put their
elisp packages in there and then add it to their load-path.  I think
we should at least try and detect this usage and emit a warning (but
we shouldn't just say "don't do that", so we need to agree on
a recommendation of where to put those packages).


        Stefan

Re: Emacs and XDG Base Dir Spec was: persistent storage for Emacs packages

[Tyler Smith]

[-- Attachment #1: Type: text/plain, Size: 327 bytes --]

On Mon, Oct 21, 2013 at 8:58 AM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

>
> Still, we have the problem with ~/.emacs.d that many users put their
> elisp packages in there and then add it to their load-path.
>
> That's exactly what I do. What is wrong with this, and what is the
preferred alternative?

Thanks,

Tyler

[-- Attachment #2: Type: text/html, Size: 736 bytes --]

Re: Emacs and XDG Base Dir Spec was: persistent storage for Emacs packages

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 1843 bytes --]

I found the discussion at the bottom of this page (Thomas Koch's 2nd
reference) helpful:

  https://wiki.debian.org/XDGBaseDirectorySpecification#state

Decomposing emacs' use of external storage more or less according to the
enumerated criteria is simply good hygiene.  It does not means that you
have to embrace the freedesktop standard.

In my own case I have already partitioned my emacs world into ~/emacs/ (a
non-hidden directory containing elements I manage via github) and
~/.emacs.d/ (everything recreatable).  In particular, with the advent of
better package management I put all downloaded packages beneath
~/.emacs.d/, on the theory that they can be recreated via download.  By
contrast I put the configuration for those packages in ~/emacs/.

/john


On Mon, Oct 21, 2013 at 8:58 AM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> > The freedesktop standards tend to come and go and change quite a bit.
> > Are we contemplating this "standard" for non-freedesktop systems also?
>
> We could work our way slowly in that direction.
>
> Currently ~/.emacs.d is pretty messy, so it might be good to try and
> "clean it up", and along the way, we could try and integrate some of
> XDG's suggestions.  Not sure how much of XDG would be useful, tho.
>
> E.g. we could start with a ~/.emacs.d/cache/ directory where all the
> files that can be reconstructed would go.  Tho there aren't many such
> files, IIRC.
>
> But w.r.t "config vs data" this distinction is far from clear.
>
> Still, we have the problem with ~/.emacs.d that many users put their
> elisp packages in there and then add it to their load-path.  I think
> we should at least try and detect this usage and emit a warning (but
> we shouldn't just say "don't do that", so we need to agree on
> a recommendation of where to put those packages).
>
>
>         Stefan
>
>

[-- Attachment #2: Type: text/html, Size: 2555 bytes --]

Re: Emacs and XDG Base Dir Spec was: persistent storage for Emacs packages

[Barry Fishman]

On 2013-10-21 09:31:16 EDT, John Yates wrote:
> I found the discussion at the bottom of this page (Thomas Koch's 2nd
> reference) helpful:
>
>   https://wiki.debian.org/XDGBaseDirectorySpecification#state
>
> Decomposing emacs' use of external storage more or less according to the
> enumerated criteria is simply good hygiene.  It does not means that you
> have to embrace the freedesktop standard.
>
> In my own case I have already partitioned my emacs world into ~/emacs/ (a
> non-hidden directory containing elements I manage via github) and
> ~/.emacs.d/ (everything recreatable).  In particular, with the advent of
> better package management I put all downloaded packages beneath
> ~/.emacs.d/, on the theory that they can be recreated via download.  By
> contrast I put the configuration for those packages in ~/emacs/.

It seems that partitioning user file should include at least 3 distinct
catagories:

user-cache-dir    Files which can be deleted between sessions, without
                  any adverse effects.
user-config-dir   init.el, custom set varables, and state information
                  maintained between sessions.  It might contain
                  packages whose source has been modified by the user.
user-package-dir  User specific packages downloaded, and maintained
                  upstream, such as (but not limited to) ELPA.

The user-config-dir does cause a bootstrapping issue, so that it might
be useful to check for an environment variable like "EMACS_CONFIG_DIR",
or initialzation switch "-config-dir=" prior to loading any user files.
This would also allow running multiple emacs configurations without
interference (very useful for testing).

The cache information might be partitioned by process ID, so that
concurrently running emacs executables can coexist without
interference.  I'm not sure if this is really an issue.

The defaults might be ~/.emacs.d/cache/, ~/.emacs.d/config/, and
~/.emacs.d/package/".

The XDG setup would be ~/.cache/emacs/, ~/.config/emacs/, and
~/.local/share/emacs/.

-- 
Barry Fishman

Re: Emacs and XDG Base Dir Spec was: persistent storage for Emacs packages

[Josh]

On Mon, Oct 21, 2013 at 6:19 AM, Tyler Smith <tyler.smith@mail.mcgill.ca> wrote:
> On Mon, Oct 21, 2013 at 8:58 AM, Stefan Monnier <monnier@iro.umontreal.ca>
> wrote:
>>
>>
>> Still, we have the problem with ~/.emacs.d that many users put their
>> elisp packages in there and then add it to their load-path.
>>
> That's exactly what I do. What is wrong with this, and what is the preferred
> alternative?

That's a good question:

    package-user-dir is a variable defined in `package.el'.
    Its value is "~/.emacs.d/elpa"

      This variable may be risky if used as a file-local variable.

    Documentation:
    Directory containing the user's Emacs Lisp packages.
    The directory name should be absolute.
    Apart from this directory, Emacs also looks for system-wide
    packages in `package-directory-list'.

Re: Emacs and XDG Base Dir Spec was: persistent storage for Emacs packages

[Tyler Smith]

[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

Another issue here is what is meant by 'package' in this context.

I have packages from elpa, melpa, etc in ~/.emacs.d/elpa. That directory
also includes development versions of packages I'm working on, installed
via package-install-file. Then there's all the bits and pieces of elisp
that I've either written myself or found online. These are stored either in
~/.emacs.d/ or a subdirectory.

I also keep the emacs sources in .emacs.d/trunk, as I'm using the latest
development version.

Everything in that directory is backed up in a private bitbucket
repository, set to ignore .emacs.d/trunk and .emacs.d/elpa.

From Stefan's comment it sounds as if I should pull everything out of
.emacs.d except init and elpa. But it's convenient for me to have emacs in
its own contained world on my computer. Is there a risk of breaking
something with this approach?

Tyler


On Mon, Oct 21, 2013 at 2:09 PM, Josh <josh@foxtail.org> wrote:

> On Mon, Oct 21, 2013 at 6:19 AM, Tyler Smith <tyler.smith@mail.mcgill.ca>
> wrote:
> > On Mon, Oct 21, 2013 at 8:58 AM, Stefan Monnier <
> monnier@iro.umontreal.ca>
> > wrote:
> >>
> >>
> >> Still, we have the problem with ~/.emacs.d that many users put their
> >> elisp packages in there and then add it to their load-path.
> >>
> > That's exactly what I do. What is wrong with this, and what is the
> preferred
> > alternative?
>
> That's a good question:
>
>     package-user-dir is a variable defined in `package.el'.
>     Its value is "~/.emacs.d/elpa"
>
>       This variable may be risky if used as a file-local variable.
>
>     Documentation:
>     Directory containing the user's Emacs Lisp packages.
>     The directory name should be absolute.
>     Apart from this directory, Emacs also looks for system-wide
>     packages in `package-directory-list'.
>

[-- Attachment #2: Type: text/html, Size: 2486 bytes --]

Re: Emacs and XDG Base Dir Spec was: persistent storage for Emacs packages

[Stefan Monnier]

> From Stefan's comment it sounds as if I should pull everything out of
> .emacs.d except init and elpa. But it's convenient for me to have emacs in
> its own contained world on my computer. Is there a risk of breaking
> something with this approach?

The problem with adding ~/.emacs.d to your load-path is one
of namespace.  E.g. Gnus expects ~/.emacs.d/gnus.el to be the user's
Gnus config.  So if you have such a file and add ~/.emacs.d to your
load-path, you'll have a conflict where (load "gnus") will load your
Gnus config file rather then loading Gnus proper.

You can use ~/.emacs.d/<subdir> instead.  But there's (so far) no
officially blessed <subdir> that we recommend.


        Stefan

Re: Emacs and XDG Base Dir Spec was: persistent storage for Emacs packages

[Josh]

On Mon, Oct 21, 2013 at 12:37 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> From Stefan's comment it sounds as if I should pull everything out of
>> .emacs.d except init and elpa. But it's convenient for me to have emacs in
>> its own contained world on my computer. Is there a risk of breaking
>> something with this approach?
>
> The problem with adding ~/.emacs.d to your load-path is one
> of namespace.  E.g. Gnus expects ~/.emacs.d/gnus.el to be the user's
> Gnus config.  So if you have such a file and add ~/.emacs.d to your
> load-path, you'll have a conflict where (load "gnus") will load your
> Gnus config file rather then loading Gnus proper.

I do not mean to nitpick, but this is the first I have heard that load-path
should not include ~/.emacs.d (or I suppose more generally
user-emacs-directory), so I would like to understand the thinking here.
I see the following in trunk:

    gnus-init-file is a variable defined in `gnus-start.el'.
    Its value is "~/.gnus"

    Documentation:
    Your Gnus Emacs-Lisp startup file name.
    If a file with the `.el' or `.elc' suffixes exists, it will be read instead.

    You can customize this variable.

Leaving aside the fact that this file is located by default in ~ instead of
~/.emacs.d, it seems that the config filename's leading dot would obviate
any namespace issue.  If that is so, are there any concrete examples of
trouble that could result from ~/.emacs.d's presence in load-path?

Re: Emacs and XDG Base Dir Spec was: persistent storage for Emacs packages

[Glenn Morris]

Josh wrote:

> If that is so, are there any concrete examples of trouble that could
> result from ~/.emacs.d's presence in load-path?

http://lists.gnu.org/archive/html/emacs-devel/2012-03/msg00056.html

Re: persistent storage for Emacs packages

[Ted Zlatanov]

On Fri, 18 Oct 2013 23:48:42 +0100 Nic Ferrier <nferrier@ferrier.me.uk> wrote: 

>> I had a similar need, and developed a system for generic persistent
>> storage from Emacs.  It lives only in my .emacs right now, but that is
>> online and freely licensed here:
>> 
>> http://svn.red-bean.com/repos/kfogel/trunk/.emacs
>> 
>> Look at the functions named `kf-persist-*' and comments therearound.
>> 
>> If it looks useful to you, I'd be fine with moving it out of my .emacs
>> and having it packaged in some more normal way.

NF> I have also written emacs-db:

NF>   https://github.com/nicferrier/emacs-db 

NF> which offers persistent hashtables basically... there is also a postgres
NF> backend using pg.el.

I like Nic's package a little better and would like to use it.  Could it
be made into a GNU ELPA package?  I would be even OK with putting it in
the Emacs core because it's such a pervasive need for so many packages
in the core and outside it.

Thanks
Ted

Re: persistent storage for Emacs packages

[Stefan Monnier]

> I like Nic's package a little better and would like to use it.  Could it
> be made into a GNU ELPA package?

We'd welcome that,


        Stefan

Re: persistent storage for Emacs packages

[Ted Zlatanov]

On Fri, 22 Nov 2013 08:40:53 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> I like Nic's package a little better and would like to use it.  Could it
>> be made into a GNU ELPA package?

SM> We'd welcome that,

CC to Nic;

Nic, would you be interested in putting emacs-db on the GNU ELPA?  Do
you need any assistance with the process?

Thanks
Ted

Re: persistent storage for Emacs packages

[Nic Ferrier]

I'd be happy to do that.

I'm a bit busy atm though.

I could get it done over christmas and commit to getting it done before
New Year.

Any good?

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Fri, 22 Nov 2013 08:40:53 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 
>
>>> I like Nic's package a little better and would like to use it.  Could it
>>> be made into a GNU ELPA package?
>
> SM> We'd welcome that,
>
> CC to Nic;
>
> Nic, would you be interested in putting emacs-db on the GNU ELPA?  Do
> you need any assistance with the process?
>
> Thanks
> Ted

Re: persistent storage for Emacs packages

[Ted Zlatanov]

On Mon, 25 Nov 2013 16:58:29 +0000 Nic Ferrier <nferrier@ferrier.me.uk> wrote: 

NF> Ted Zlatanov <tzz@lifelogs.com> writes:

>> On Fri, 22 Nov 2013 08:40:53 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 
>> 
>>>> I like Nic's package a little better and would like to use it.  Could it
>>>> be made into a GNU ELPA package?
>> 
SM> We'd welcome that,
>> 
>> CC to Nic;
>> 
>> Nic, would you be interested in putting emacs-db on the GNU ELPA?  Do
>> you need any assistance with the process?

NF> I'd be happy to do that.
NF> I'm a bit busy atm though.

NF> I could get it done over christmas and commit to getting it done before
NF> New Year.

NF> Any good?

Works for me.  It should be literally a 15-minute task :)

Ted