On Tue, 22 Feb 2005, Stephen J. Turnbull spake: That's OK: I expected people to have to think about it. I'd do that (if I had commit privs, which I don't), except that this package seems not very useful in unsupported: the point of it is that people *maintaining packages* make calls to it whenever they change a default, and if it was in unsupported, they couldn't very well do that. Obviously, it can be in unsupported while people review it and work out if the idea makes sense: but if it does, this is the sort of thing which might even end up dumped. (In that situation, I guess commit privs might be useful.) Good idea. (We're already partway towards package-bootstrap, of course, except that we'd need xemacs-base and efs in there too...) Good division. (defaults.el would be in the standard library by that definition.) A few core packages might need to split: parts of files.el are defintely core, while parts (interpreter-mode-alist!) are probably standard library. The edges there can probably blur a bit without too much harm. But surely our *current* division needs fixing: `xemacs-base' just seems to mean `stuff that could be in core but we want to be usable in several Emacs versions', which is mixing two orthogonal things together (distribution method and XEmacs-versions-we-run-under). Good idea. (Goodbye to the `I can't download packages!' newbie error.) It's completely nondisruptive, I hope -- or at least it can't break your box worse than you broke it yourself at some point in the past :) That's probably a good place for it --- although many of the most important XEmacs defaults are located in core, and if defaults.el goes into xemacs-base, the core stuff can't use it, can it? (Is core allowed to call stuff in xemacs-base? If xemacs-base is always required to be there, then I guess defaults.el could go in xemacs-base without incident. With packages-in-source-tree, I guess that would be true...) Yes. Unless the database gets truly vast, a Lisp library could handle it perfectly well; you don't need any more than print and read :) see BBDB for an existence proof with a database far larger than I expect the defaults list ever to get. Otherwise, as you say, we have a dbm module for a reason :) That was actually semi-intentional: the idea was to track `the way XEmacs behaved' and let you freely revert it to `exactly the way it was'. But yes, it might be a good idea to extend things so that you can say something like (defaults-as-at "2005-01-09" 'package) to roll back only package-triggered changes (the default still being 'all). That way you can catch package changes while ignoring your tasteless admin's ugly hacks, or catch your admin's site-wide config updates while ignoring the horrible config changes the XEmacs team have perpetrated since you started using lemacs in 1836. (`l' *does* stand for `loom', doesn't it? ;} ) I'd quite like `defaults-changed-at' to be able to detect whether it was called from a package, a subpackage of site-start/default.el, or a user Lisp file itself, so that the interface stays simple and the admins and package maintainers need to know no more than the absolute minimum: do you know any way for defaults-changed-at to detect this? (Is there a variable that's bound while user and site lisp is being executed, or something like that? Or can I tell that the caller was stored in a package tree?) (This is really just a pious hope: I doubt there's a way of telling, but if there's one thing I've learnt about XEmacs, it's that there's a way to coerce it into doing virtually *anything*... ;) ) -- What we need these days is a stable, fast, anti-aliased root beer with dynamic shading. Not that you can let just anybody have root. --- John M. Ford