[PATCH] defaults.el: record and revert changing XEmacs defaults across time
Stephen J. Turnbull
stephen at xemacs.org
Tue Feb 22 02:56:18 EST 2005
Sorry for letting this go so long. Moving discussion to xemacs-beta.
Nix, if you have commit privileges in the packages, you can just
create an unsupported/nix directory and put anything you want (that
won't get us or our hosts sued, of course) there. If you don't, we
should fix that, but I could create the directory in the meantime.
>>>>> "nix" == nix <nix at esperi.org.uk> writes:
nix> Have a package, everyone.
nix> I'm not sure where it belongs; if we want both core *and* the
nix> packages to be able to use it (which is kind of the point),
nix> we're in a bit of a bind. Can core reasonably require new
nix> packages when you upgrade it, or are they completely
nix> decoupled? (I seem to recall a change to auto-mode-alist
nix> construction in core that required new packages...)
I've been working on packages-in-source-tarball recently, with the
idea being two options: sumo-in-source, and package-bootstrap (enough
to download packages from ftp.xemacs.org).
What I have in mind is a three-tier approach: application packages,
standard library packages, and core. Core implements the Lisp
language and the editor primitives; the standard library implements
the standard editor functionality and hides backward-incompatible core
changes from the applications and (optionally) provides common
functionality such as mail-lib; and the applications are applications.
Then the source for the standard library packages (such as
xemacs-base) would live in the package source tree, but would be
distributed in a new standard-library tarball which would be included
in source distributions that don't include the whole sumo.
nix> If the core can force new packages, it should probably go in
nix> xemacs-base... packages certainly can't require a new core,
nix> so it can't go in core if we want the packages to be able to
nix> use it without testing.
nix> (This sounds rather backwards to me, given the sort of things
nix> core contains; i.e., standard XEmacs things that the packages
nix> can use without testing, but I understand why it's the case.)
Well, there are arguments both ways.
nix> Anyway, wherever it goes, here it is for people to laugh
nix> at. (Adjust the (not) in the heading comments if you actually
nix> accept it.)
Actually the code hardly looks laughable to me. I haven't actually
had a chance to try it, mind you .... ;-) Once I've done that, maybe
we can add it to xemacs-base.
I think something we should consider for the future is some kind of
out-of-RAM database (use dbm or even just a lisp library).
It also could get a submenu under help, with the submenu containing
the list of default-changed-dates known to XEmacs.
The main "bug" I see is that there doesn't seem to be any way to
determine whether the site admin or a user changed a default, or if
some package did. Maybe we could have a flag that if set would allow
defaults.el to revert "rogue" changes.
The code is at
Institute of Policy and Planning Sciences http:
More information about the XEmacs-Beta