Best practice for sharing new Emacs modules

Best practice for sharing new Emacs modules

[Matthew Leach]

Hi all,

I've begun work on a new mode for Emacs that allows editing of gpg keys
in a dired-like fashion -- something I said I was going to do a long
time ago!  I'm making good progress and am hoping to post to the list
very soon for feedback.

I do have one question: what is the best/accepted way to share the code
with the Emacs community?  I've looked around at the Emacs source tree
for advice, but all I could find was notes about posting patches for the
Emacs source tree itself, rather than a new module.  Would a simple
email to the list with the code attached suffice or would I be better
hosting the code on my github and providing a link to it on this list?
Do people even care?

Apologies for a (probably) pointless question, it's my first time
writing a new Emacs module and I'm trying to avoid the dreaded
development faux pas.
-- 
Matt

Re: Best practice for sharing new Emacs modules

[Clément Pit--Claudel]

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

On 01/11/2016 02:43 PM, Matthew Leach wrote:
> Hi all,
> 
> I've begun work on a new mode for Emacs that allows editing of gpg keys
> in a dired-like fashion -- something I said I was going to do a long
> time ago!  I'm making good progress and am hoping to post to the list
> very soon for feedback.
> 
> I do have one question: what is the best/accepted way to share the code
> with the Emacs community?  I've looked around at the Emacs source tree
> for advice, but all I could find was notes about posting patches for the
> Emacs source tree itself, rather than a new module.  Would a simple
> email to the list with the code attached suffice or would I be better
> hosting the code on my github and providing a link to it on this list?
> Do people even care?
> 
> Apologies for a (probably) pointless question, it's my first time
> writing a new Emacs module and I'm trying to avoid the dreaded
> development faux pas.

I'm not an expert, but I think relevant keywords here are ELPA and possibly MELPA :)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Best practice for sharing new Emacs modules

[Artur Malabarba]

2016-01-11 17:43 GMT-02:00 Matthew Leach <matthew@mattleach.net>:
> I do have one question: what is the best/accepted way to share the code
> with the Emacs community?

1. You can send us the .el file and ask to have it included in GNU
Elpa (this means it will show up for anyone who runs `M-x
list-packages').

2. You can push it to Github and then have it included on Melpa (see
https://github.com/milkypostman/melpa for instructions).

These two options are not mutually exclusive, but they're pretty
redundant, so I'd recommend just choosing one.

RE: Best practice for sharing new Emacs modules

[Drew Adams]

> > I do have one question: what is the best/accepted way to share
> > the code with the Emacs community?
> 
> 1. You can send us the .el file and ask to have it included in GNU
> Elpa (this means it will show up for anyone who runs `M-x
> list-packages').
> 
> 2. You can push it to Github and then have it included on Melpa (see
> https://github.com/milkypostman/melpa for instructions).
> 
> These two options are not mutually exclusive, but they're pretty
> redundant, so I'd recommend just choosing one.

You can also post in on Emacs Wiki, in the Elisp Area:
http://www.emacswiki.org/ElispArea

And then send a message to contact@milkbox.net with a simple recipe
for inclusion in MELPA.  MELPA can pick up libraries automatically
(e.g. daily) from GitHub or the wiki.  For the wiki, you just need
to provide a recipe.

A "recipe" can be as simple as this, where the part after `;' is
a short description.

 (character-fold+ :fetcher wiki) ; Extensions to `character-fold.el'.

If the library includes multiple files then the recipe is a bit
more involved.  You can contact contact@milkbox.net for more info.

Re: Best practice for sharing new Emacs modules

[Clément Pit--Claudel]

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

On 01/11/2016 04:43 PM, Drew Adams wrote:
> You can also post in on Emacs Wiki, in the Elisp Area:
> http://www.emacswiki.org/ElispArea
> 
> And then send a message to contact@milkbox.net with a simple recipe
> for inclusion in MELPA.  MELPA can pick up libraries automatically
> (e.g. daily) from GitHub or the wiki.  For the wiki, you just need
> to provide a recipe.

This won't work: Wiki recipes are not accepted anymore:

  > New recipe submissions should adhere to the following guidelines,
  >  * Upstream source must be stored in an authoritative SCM repository. EmacsWiki recipes are no longer accepted.

Cheers,
Clément.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Best practice for sharing new Emacs modules

[John Wiegley]

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

>>>>> Matthew Leach <matthew@mattleach.net> writes:

> I've begun work on a new mode for Emacs that allows editing of gpg keys in a
> dired-like fashion -- something I said I was going to do a long time ago!
> I'm making good progress and am hoping to post to the list very soon for
> feedback.

We would welcome your change in ELPA; you need only a copyright assignment on
file with the FSF to do so. You can send the file directly to me if you have
such an assignment, and I can add it for you.

I'd also like to use your package, as I'm currently using a GUI program to
manage my program and would prefer to be using Emacs. :)

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Best practice for sharing new Emacs modules

[Stefan Monnier]

> I do have one question: what is the best/accepted way to share the code
> with the Emacs community?

IMO the best way is to add it to GNU ELPA and to use GNU ELPA's elpa.git
repository as the main repository of the package.


        Stefan