[Top][All Lists]

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

Re: package.el

From: David Reitter
Subject: Re: package.el
Date: Mon, 21 May 2007 23:43:24 +0100

On 21 May 2007, at 18:40, Tom Tromey wrote:

David> *scratch* is not guaranteed to be in emacs-lisp-mode. So C-j might
David> not work. M-x eval-region would!

I wasn't aware of this.  Is this a common situation?  Those
instructions are intended for people who know very little about Emacs;
are they likely to have changed the mode for *scratch*?

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

Yes, I agree.  I don't know much about custom (my last emacs lisp
hacking experience predates the existence of custom -- sad but true).
But I will learn and I'll make the appropriate fix.

However, for the installer, I think this is an ok choice.

Well, in a distribution, this is what one wants to customize - simply because ~/.emacs.d is not a [standard] directory on all operating systems. I don't know what Windows does, but on the Mac, such extensions go into ~/Applications/Application Support/Emacs/... - which is something a CVS (GNU) Emacs doesn't do. But a distribution of GNU Emacs (such as Aquamacs) knows these directories.

and use features like this probably won't have much trouble hand
installing package.el.

Yes, if it's a standard package that provides a new feature - sure no problem. That's what would be included in a distro anyways.

Yes.  package.el knows a bit about which packages are shipped as part
of Emacs.  This supports one of the use cases I was interested in,
something I've run into a reasonable number of times.

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

In package.el this is solved by knowing the versions of large packages
which are included in Emacs.  This list isn't complete though -- known

Yes, bug. I would check the versions of all installed packages at compile time (install time), going through Emacs' load path. Or, perhaps better, you check for installed versions just when you actually need to know, i.e., when the user wants to install another package. As a distributor, I would not enable a feature that will slow down the application startup.

I suppose my ideal situation here would be for distros to support
package.el directly (my real ideal was to get this into Emacs itself
but that is looking less likely :-).

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

reply via email to

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