On Tue, 22 Feb 2005, Stephen J. Turnbull spake:
Sorry for letting this go so long. Moving discussion to xemacs-beta.
That's OK: I expected people to have to think about it.
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.
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.)
>>>>> "nix" == nix <nix(a)esperi.org.uk>
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
Good idea. (We're already partway towards package-bootstrap, of course,
except that we'd need xemacs-base and efs in there too...)
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.
Good division. (defaults.el would be in the standard library by that
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).
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.
Good idea. (Goodbye to the `I can't download packages!' newbie error.)
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 .... ;-)
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 :)
Once I've done that,
we can add it to xemacs-base.
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
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.
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 :)
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.
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*... ;) )
...Hires Root Beer...
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