mike.kupfer(a)xemacs.org writes: The potential problem is that we don't have a good way to inform users that they need Version X.Y of xemacs-base. If putting runtime-future.el into xemacs-base was a good solution, I don't see why we'd need a separate compile-time version. Also, if you put it into xemacs-base, it gets compiled. The inability to run uncompiled macros from bytecode means that in principle every version of XEmacs needs a different compiled version of xemacs-base. The history of the APEL package shows that this is a practical problem, too. The real solution is to have a standard-library package (or package suite) which is shared between all reasonably recent XEmacs versions. (This is the real long-term motivation for the "bundled-packages" work.) Versions of XEmacs without C support for certain features would have to do without, or perhaps use inefficient Lisp versions. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta