Jari> What do you think about adding version information? We can't "add version information" because it's already there (those are not control characters, I edited them): ;ELC^T^＠^＠^＠ ;;; compiled by steve(a)tleepslib.sk.tsukuba.ac.jp on Fri Jan 19 13:27:26 2001 ;;; from file /home/steve/Projects/XEmacs/Builds/21.2/lisp/subr.el ;;; emacs version 21.2 (beta40) "Persephone" XEmacs Lucid. ;;; bytecomp version 2.27 XEmacs; 2000-09-12. ;;; optimization is on. ;;; this file uses opcodes which do not exist in Emacs 19. What more can you ask for? The optimizer doesn't add any new codes, so having a version for it would be nice but not essential. Rather than depend on the version header, the loader or the byte-code interpreter (maybe both, for maximum flexibility) should scan for illegal byte codes and behave appropriately when they are detected. This allows a flexible response to known but unimplemented byte codes, and also allows the loader to respond reasonably to files that are simply corrupt. It probably would be nice to have an option to automatically back up to the .el, and either load it directly or byte-compile-and-load it. But this is GNU's problem, not ours. We can't fix their loader/interpreter. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

"Martin" == Martin Buchholz <martin(a)xemacs.org&gt; writes: Martin> Adding version information to the .elc file is an excellent Martin> idea. Using the emacs version number would not be enough, Martin> because different emacsen with the same version number might Martin> have incompatible bytecodes. The Emacs version number might not be sufficient, but it could be useful in any case. This is maybe drifting off-topic, but the discussion reminded me of the `emacs-vers.el' package that I wrote many moons ago. It has the ability to evaluate Emacs version predicates at byte-compile time. One advantage of this is that one can avoid byte-compiler warnings that arise merely from cross-Emacs and cross-version compatibility code. A problem with the existing package, however, is that there is nowhere in the `.elc' to put the compile-time assumptions. I could have further hacked the byte-compiler myself, but I didn't. What I would have liked was a standard byte-compiler hook in which one could specify load-time predicates to verify compile-time assumptions. This is more than what is needed to check for byte-code compatibility, but if you're going to muck about in that part of the compiler anyway, why not make a hook for program specializers? Like I said, probably drifting off topic. Eric. PS --- <http://www.cs.utah.edu/~eeide/emacs/emacs-vers.el.gz> -- ------------------------------------------------------------------------------- Eric Eide <eeide(a)cs.utah.edu&gt; . University of Utah School of Computing http://www.cs.utah.edu/~eeide/ . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX