running multiple Emacs versions

running multiple Emacs versions

[nchubrich]

I would like to run both Aquamacs and a compiled version of Emacs 23,
for different purposes.  Presumably they will need different
configurations.  How can I do this, seeing as there is one .emacs
file?

Thanks,

Nick Chubrich.

Re: running multiple Emacs versions

[Peter Dyballa]

Am 12.02.2010 um 20:47 schrieb nchubrich:

> I would like to run both Aquamacs and a compiled version of Emacs 23,
> for different purposes.  Presumably they will need different
> configurations.

Why do you think so? Do you know that Aquamacs Emacs has inside its  
application bundle some extra startup files?

--
Greetings

   Pete

Claiming that the Macintosh is inferior to Windows because most people  
use Windows, is like saying that all other restaurants serve food that  
is inferior to McDonald's.

Re: running multiple Emacs versions

[Tim X]

nchubrich <nicholas.chubrich@gmail.com> writes:

> I would like to run both Aquamacs and a compiled version of Emacs 23,
> for different purposes.  Presumably they will need different
> configurations.  How can I do this, seeing as there is one .emacs
> file?
>
> Thanks,
>
> Nick Chubrich.

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
)

HTH

Tim

 


-- 
tcross (at) rapttech dot com dot au

RE: running multiple Emacs versions

[Drew Adams]

> 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.

Re: running multiple Emacs versions

[nchubrich]

Tim---

Thanks, initz sounds like what I am looking for---do you happen to
know how to access the source without a debian package manager, since
I am on Mac OS X?  The download link is here: http://packages.debian.org/sid/initz

Drew---

Regarding .elc files, aren't most of these placed in the individual
App directories on Mac OS X, i.e. Aquamacs.app, Emacs.app?  When you
refer to "byte compiling", do you mean Emacs LISP packages you have
written, or are you talking about installing external packages say
from Elpa?

Thanks for all your help!

On Feb 12, 8:04 pm, "Drew Adams" <drew.ad...@oracle.com> wrote:
> > 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.

Re: running multiple Emacs versions

[Tim X]

nchubrich <nicholas.chubrich@gmail.com> writes:

> Tim---
>
> Thanks, initz sounds like what I am looking for---do you happen to
> know how to access the source without a debian package manager, since
> I am on Mac OS X?  The download link is here: http://packages.debian.org/sid/initz
>

From the initz README file 

  For more information, see the Initz web page at

    http://www.koka-in.org/~bg66/index.cgi?cmd=view;name=Initz

Development
-----------

  Development of Initz uses CVS, Concurrent Versions System. Latest
  development version is available via CVS.

  * cvs login (first time only)

    % cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/root login
    (CVS password: [CR] # NULL string)

  * checkout modules

    % cvs -d :pserver:anonymous@cvs.m17n.org:/cvs/root checkout initz
 
  Browsing the CVS tree gives you a great view into the current status of
  this project's code. You may also view the complete history of any file
  in the repository.
  Please refer to <URL:http://cvs.m17n.org/cgi-bin/viewcvs/initz/>.

  If you would like to join CVS based development, please refer to
  <URL:http://cvs.m17n.org/>.

Bug reports
-----------

  If you have bug reports and/or suggestions for improvement, please send
  them to bg66@koka-in.org.

References
----------

  * http://deisui.bug.org/cgi-bin/viewcvs.cgi/dot-xemacs/README?rev=HEAD

  * http://triaez.kaisei.org/~kaoru/emacsen/startup/INSTALL.ja

  * http://www.unixuser.org/~ysjj/emacs/

  * http://www.sodan.org/~knagano/emacs/dotemacs.html

I personally found initz too heavy weight for my requirements, but it
had lots of good ideas which I used in hacking together something less
powerful, but simpler that met my needs.

Tim


-- 
tcross (at) rapttech dot com dot au

RE: running multiple Emacs versions

[Drew Adams]

> Drew---
> 
> Regarding .elc files, aren't most of these placed in the individual
> App directories on Mac OS X, i.e. Aquamacs.app, Emacs.app?

I have no idea.

In the GNU Emacs distributions I use, the distributed *.elc files are in
directory `lisp' or one of its subdirectories. `lisp' itself is in the directory
where Emacs is installed.

> When you refer to "byte compiling", do you mean Emacs LISP
> packages you have written, or are you talking about installing
> external packages say from Elpa?

Most of what I wrote was about "byte-compiled" files, which includes those
distributed by GNU. It doesn't matter who byte-compiled a file, what kind of
*.el file was byte-compiled, or where the *.elc is stored. My point was about
compatibility among different Emacs versions with respect to byte-compiled
files.

When I spoke of byte-compiling files myself, I meant any files for which I have
a *.el and no *.elc or a *.el that is more up-to-date than the *.elc. That
includes files I've written and files from others. (I don't modify the files
distributed with Emacs, so I don't need to byte-compile them again.)

The main points were:

1. You can generally use a *.elc produced (byte-compiled) using an older Emacs
version.

2. You can use `emacs-major-version', `(require ... nil t)' or `featurep',
`fboundp', and `boundp' to check which version of Emacs, a feature, a function,
or a variable you are using. 

Re: running multiple Emacs versions

[Pascal J. Bourguignon]

nchubrich <nicholas.chubrich@gmail.com> writes:

> I would like to run both Aquamacs and a compiled version of Emacs 23,
> for different purposes.  Presumably they will need different
> configurations.  How can I do this, seeing as there is one .emacs
> file?

I use the same .emacs for all my emacsen.
(Well, for one thing, I reduce the problem by using only GNU emacsen).


The only specific settings I have for aquamacs are:



(when (or (boundp 'aquamacs-version)
          (eq window-system 'ns))
  (setf mac-command-modifier 'meta
        mac-option-modifier  'alt
        one-buffer-one-frame nil
        initial-frame-alist '((background-color . "#ddffee")
                              (left . 76)
                              (top . 20)
                              (width . 80)
                              (height . 60))
        default-frame-alist (append initial-frame-alist default-frame-alist)
        cursor-type 'box)
  (cua-mode 0)
  ;; Perhaps the following is not needed for you or the current version:
  (when (fboundp 'smart-frame-positioning-mode)
    (smart-frame-positioning-mode nil))
  (when (load "scroll-bar" nil t)
    (defun scroll-bar-columns (side)
      "Return the width, measured in columns, of the vertical scrollbar on SIDE.
SIDE must be the symbol `left' or `right'."
      (let* ((wsb   (window-scroll-bars))
             (vtype (nth 2 wsb))
             (cols  (nth 1 wsb)))
        (cond
         ((not (memq side '(left right nil)))
          (error "`left' or `right' expected instead of %S" side))
         ((and (eq vtype side) cols))
         ((eq (frame-parameter nil 'vertical-scroll-bars) side)
          ;; nil means it's a non-toolkit scroll bar, and its width in
          ;; columns is 14 pixels rounded up.
          (ceiling (or (frame-parameter nil 'scroll-bar-width) 14)
                   (frame-char-width)))
         (0))))))


Here are a set a variable you can use to implement variable
configurations:

system-type          darwin   gnu/linux   cygwin
system-name          "naiad.informatimago.com" "hermes.afaa.asso.fr"
system-configuration "i686-pc-linux-gnu" "i686-pc-cygwin" "i386-apple-darwin9.8.0"
window-system        nil x mac ns w32
emacs-major-version  18 19 20 21 23
emacs-minor-version  0 1 2 3
emacs-version        "20.7.2" "21.2.1" "23.0.94.1" "23.1.1"
aquamacs-version     "2.0preview3"

But of course, you should try to keep the most common .emacs.
You may also use boundp and fboundp, and (when (require 'xxx nil t) ...)
to avoid errors when something is missing.

-- 
__Pascal Bourguignon__