Re: reftex needs to be upgraded.

Hans de Graaff writes: Excuse me, but by design the released package *is* the versioned source. That was an absolute design requirement of the whole package system: you had to be able to modify and rebuild the package (as installed, not the tarball), either in-place or in a separate tree. The CVS tree is a version with different meta-content, with the purpose of facilitating contributions to the XEmacs project. However, if you want to contribute changes made in-place, of course we accept patches against the original installed files rather than against CVS. This is way less than ideal, actually, since the user may not have the same versions of packages installed as the sources expect. So now you have completely lost control over the content of the installed .elcs. This is a design problem with Emacs Lisp macros. Even with GNU Emacs with its monolithic distribution of all Elisp they care about, if the user has anything like a CVS version of APEL in their environment, you will lose, because those guys monkey-patch the core. I'm not saying rebuilding in the user's environment is a bad idea; often it's a great idea. But there are potential problems with it, it's not *ideal*. I don't understand what you mean by "properly install". Just cp -a the contents of an unpacked -pkg.tar.gz, after any modifications you like, and recompiling. Or tar it up. That is an "XEmacs package", in the sense that it will work in any installed XEmacs package system without screwing up the installations of other packages.[1] I'm not sure if the same applies to the TeX and Java code in packages like AUCTeX and JDE, but I don't see why it wouldn't. The only problem would be build-time detection of external executables, libraries, and the like, but AFAIK both AUCTeX and JDE have solved those problems so that prebuilt, working packages can be untarred into the package tree and Just Work. What exactly do you want to "get working"? Compiling in the user's environment is trivial, but versioning any compiled Elisp is really, really hard; we've never been able to get a complete handle on dependencies (darn autoloads ...). Footnotes: [1] Of course it's not an official XEmacs package, in the sense that we will refuse to distribute it. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta