Re: forward-compat (was: Re: [Q21.4] Re: [patch] [21.5] derived.el - put `derived-mode-parent' property on child, plus sync `derived-mode-p')

Ben, I know you've done some thinking about this kind of issue w.r.t moving libraries back and forth between core and package. This is a different issue, maintaining a compatibility library that hopefully would avoid the problems we have with APEL, for the benefit of users. But not that different, I think. Any comments appreciated. jpw> I think the compat package is a nice idea. When you say "set jpw> it up" what do you mean? Is there already an emacs lisp jpw> file? Perhaps the least-hassle method is to put it in jpw> unsupported for now. I think that when we set it up it should go into xemacs-packages, but not into SUMOs, until we're pretty sure it's working. jpw> Given that this thing is work, another cost of compatibility jpw> borne by the XEmacs maintainers, maybe it should be put off jpw> until there is greater need or demand for it. On net it should pay for itself quickly. It gives us an official place to put stuff that is a really good idea, but the core engineers are wary of putting in the distro, and so (1) saves the core people skull-sweat, and (2) everybody who participates in the mailing lists FAQs (or at least provides a ready answer), and (3) lots of user and 3rd party developer hassle. As for the maintainer effort as such, a little extra effort comes from Ville and Rendhalver, balanced by a lot saved from me. That's up to those guys since they're paying ;-). Then there's the upfront cost. Mostly we need to work out some way, plus a convenient interface, that a user can say "I want this, and that, and all of these except those, and definitely not the other thing". Probably a custom-style interface. Something like each fix gets a number, one or more version specs, and zero or more classes. The customization for each fix is (choice 'default 'hit-me 'go-away), and similarly for classes. The version spec would be compared to compatibility-version, which would (of course) default to (major minor patchlevel). So in the compatibility library you get something like (provide 'xemacs-compatibility-library) (compatibility-install-if '(1 (compatibility-version<= 21 4 9) 'gnu-compatible 'bug-fix) "This patch installs John Paul Wallington's synch of the FROBOZZ argument to the schnickelfritz function for GNU Emacs compatibility. You need it if you see Wrong Type Argument: frobotzim, nil when using the Gnoose.el package for punishing Capitols. This overwrites the core definition of `schnickelfritz'." :group xemacs-compatibility :type (choice 'default 'install 'do-not-install) (defun schnickelfritz (frobozz) (make-frobotzim frobozz))) Semantics (how to resolve the conditional): If the version spec is not satisfied, don't install. Otherwise, if fix #1 has a non-default spec, obey it. Otherwise, if any of its classes are refused, don't install. Otherwise, if any of its classes are requested, install. Otherwise, don't install. This is moderately flexible and convenient, but behaves conservatively with respect to cases where the user can't really know what's good for her (class specs). The logic is easy to write and prove. The widget for customizing would not only present the docstring, but it would also snarf out the patch number, version spec, and classes. We could actually partially enforce the doc standard by requiring :indication (for when you need it) and :functionality (new v. modified) tags. The main hassle here would be updating version specs. But I kinda think we (== me, Vin, and Steve Y) have to do that. We can't just leave the version spec open. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py