Jonathan Underwood jonathan.underw...@gmail.com writes:
Hi,
So, while filing a bunch of bugs against packages not complying with
the Emacs add-on packaging guidelines, I started to think about the
state of add-ons for Emacs [1].
Since those guidelines were put in place, Emacs has grown its
On 24 June 2015 at 08:01, Jan Synacek jsyna...@redhat.com wrote:
Jonathan Underwood jonathan.underw...@gmail.com writes:
The Emacs package manager installs these add-on modules in the user's
own directory by default, but it can also install them in a system
wide directory.
If you run Emacs
Jonathan Underwood jonathan.underw...@gmail.com writes:
On 24 June 2015 at 08:01, Jan Synacek jsyna...@redhat.com wrote:
Jonathan Underwood jonathan.underw...@gmail.com writes:
So, I am not really sure what a good way forward is at this point.
Certainly package.el could be extended to help us
On 06/24/2015 07:31 AM, Jonathan Underwood wrote:
On 24 June 2015 at 08:01, Jan Synacek jsyna...@redhat.com wrote:
Managing Emacs packages by the distribution makes, IMHO, no sense at
all. Users can easily manage the packages themselves via Emacs'
package.el user interface.
Well, that's the
Hi,
So, while filing a bunch of bugs against packages not complying with
the Emacs add-on packaging guidelines, I started to think about the
state of add-ons for Emacs [1].
Since those guidelines were put in place, Emacs has grown its own
package manager (package.el, shipped with Emacs[2]), and
The case I just fixed is a bit different - it's not something that comes
from elpa, melpa, etc., but is an add-on that was just a contributed part
that ships with mercurial. Probably many cases of emacs-foo fedora packages
are like this.
--
devel mailing list
devel@lists.fedoraproject.org
On 23 Jun 2015 20:06, Neal Becker ndbeck...@gmail.com wrote:
The case I just fixed is a bit different - it's not something that comes
from elpa, melpa, etc., but is an add-on that was just a contributed part
that ships with mercurial. Probably many cases of emacs-foo fedora
packages
are like
