[PATCH] defaults.el: record and revert changing XEmacs defaults across time

[Stephen J. Turnbull]

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

http://list-archive.xemacs.org/xemacs-patches/200502/msg00059.html

see also

http://list-archive.xemacs.org/xemacs-patches/200502/msg00040.html

-- 
Institute of Policy and Planning Sciences     http: