Re: package.el

[David Reitter]

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
> bug.

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.