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

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> 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: