sb> Dang it! We don't want people writing version number tests! sb> They should be writing feature tests. Please, pretty please, do advertise this loud and clearly ! I have been using XEmacs for about five years now and was up-to-now unaware about them. When exactly and on what basis are they initialised (i.e. are features like gnus available after I startup xemacs or as soon as I load my .gnus ? Coming from a CL-world, I always thought, that features are available as soon as they are provided. So, when I don't load a *.el{c}-file how could it provide a feature ? Or, more precisely, where is the TFM that I can R ?) ;;; Define a function to make it easier to check which version we're ;;; running. (defun running-emacs-version-or-newer (major minor) (or (> emacs-major-version major) (and (= emacs-major-version major) (>= emacs-minor-version minor)))) ... (cond ((and (not running-xemacs) (>= emacs-major-version 19)) ;; ;; Code specific to FSF Emacs 19 (not XEmacs/Lucid Emacs) goes here ;; )) feature-tests are IMHO not enough. There are some people who need to support different emacs-versions using different packages (and different versions, of course). So, there will be people who will need to support such version number tests, but hey, I guess, that they will be able to write three-digits-version tests anyway (however, they will be annoyed to death if they have to. I can't think of an instance where one would be forced to do). I would really like to see some intelligent packaging scheme [1] in the sense of RPM or .deb-packages which clearly states what is required for the current package to run, e.g. which emacs-version or which elisp-facility. This would really allow an intelligent "feature test" and get rid of such awful cond-schemes. Holger PS: Steve, I just noticed that browse-cltl2 provides itself as ilisp-browse-cltl2, which is completely nonsense. Please change it to just browse-cltl2, diff is included below. Footnotes: [1] at best to be incorporated into the current package mechanism