emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: package.el


From: Tom Tromey
Subject: Re: package.el
Date: Mon, 21 May 2007 16:51:21 -0600
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.95 (gnu/linux)

>>>>> "David" == David Reitter <address@hidden> writes:

David> default-major-mode's default value is text-mode in Aquamacs.
David> *scratch* is in text-mode by default.

Ok.  I will update the text to account for this somehow.

David> Well, in a distribution, this is what one wants to customize -
David> simply because ~/.emacs.d is not a [standard] directory on all
David> operating systems.

I simply followed existing practice that I found in Emacs.  FWIW I
think it would make sense to make this a customizable setting used
everywhere that "~/.emacs.d" is currently used.

Does Aquamacs have a setting for this?  package.el could conditionally
use that.

David> OK, please don't forget cases where a distribution installs
David> additional packages. Both distributions on the Mac do that, and I
David> presume the Windows binaries come with some add-ons, too. And you,
David> yourself, mentioned Fedora's dislike for Tetris, etc.

Yes.  The issue is expressing this in an efficient way to package.el.

David> It's more realistic to make package.el work in the way Emacs already
David> finds and loads its packages, rather than requiring distributors to
David> maintain a separate database of file versions (even though that would
David> be a sensible thing to do). This could be done via a standard symbol
David> feature-version' where "feature" stands for the name of the feature
David> that is `provide'd, or via the subfeatures argument to `provide'. I
David> don't know what is already in place in package.el.

Currently this is done by loading the "-pkg.el" file from the package,
which then invokes define-package.

This is ok if you don't have a huge number of packages.  If we ever
get there then perhaps I'll need to think about a new approach.

I don't see how feature-version would be defined until a package is
loaded -- but that is what we want to avoid.

My (former) plan for incorporating this into the core was to extract
this info when Emacs is built.  Anyway, I'm open to suggestions but,
again, I'm a bit unsure whether this is the appropriate forum for
discussion.

Tom




reply via email to

[Prev in Thread] Current Thread [Next in Thread]