RE: running multiple Emacs versions

["Drew Adams" <drew.adams@oracle.com>]

> Using one .emacs file is probably not going to be the big issue. Your
> problem is likely to be byte code incompatibility, especially as emacs
> 23 moved to utf-8 encoding, which makes the *.elc files incompatible
> with versions prior to 23. Emacs 23 can read older *.elc files, but it
> does a translation/conversion process 'on the fly' which can
> substantially slow down file loading etc.
> 
> There are ways around all of this, but take a bit of work. As an
> example, you cold look at how Debian/Ubuntu handle running multiple
> emacs versions at the same time. For your init file, look at 
> initz (see emacs wiki). I htink there is some other info on this
> in the wiki as well. 
> 
> For your .emacs, you may be able to just get by using simple 'when'
> blocks for the version specific stuff i.e.
> 
> (when (= emacs-major-version 23)
>   ;; do 23 specific stuff
> )

Everything Tim said is true, I believe.

But as (only) one data point (FWIW), I routinely byte-compile in Emacs 20 (or in
22, if the library isn't designed for 20/21), and then use the *.elc in more
recent versions, including Emacs 23. I haven't particularly noticed any slowdown
(but I don't doubt that there is one, at least theoretically).

However, some Emacs 23-specific features are available only if you byte-compile
the code in Emacs 23. Likewise, some Emacs 22-specific features need to be
compiled using Emacs 22 (or 23). So while byte-compiling using an older release
generally works and I haven't noticed a slowdown, you might lose some features
that are specific to more recent releases. In practice, this is pretty rare,
however (IMO/experience).

Wrt version testing, to protect/expose various code sections (e.g. in your init
file): Yes, `emacs-major-version' is your friend.

But if you know something more specific about the code that is needed from that
release, then it's often better to test for the presence of that specific
object.  Testing the Emacs version is generally a last resort, but sometimes it
is the most appropriate thing to do.

You can test for a given feature (library) using (require... nil t) - or
`featurep' if already loaded. You can test for the presence of a specific
function using `fboundp'. You can test for the presence of a specific variable
using `boundp'.

(What's not so easy to test for is a specific function signature. If a function
has a different number of arguments in different releases, then about the only
way to test which is which is to use `condition-case' and tempt an error.)

HTH.