Writing Portable Emacs Code

Here is some experiences I have had with writing emacs lisp code for both major Emacs variants.

General Advice

Use a common API when possible.
If you need some functionality provided by one emacs but missing in the other, write an emulation library. Be sure to be as faithful to the original as possible. Try to get your emulation included in the other emacs.
Try to avoid using conditional based on emacs version. I.e. avoid (string-match "XEmacs" emacs-version) when possible.
Instead, test for the feature you want to use, e.g. use fboundp before calling an version specific function.

When that is not possible, use

(condition-case nil
    (emacs-code)
  (error (xemacs-code)))

Don't worry too much about supporting old versions. Some people will have to wait a few month extra to use your code, but no longer than they have to wait for all the other goodies that come with the new emacs.

Specific Advice

Key Bindings

Use the XEmacs format for key bindings.

(define-key [(shift tab)] 'field-backward)

Avoid the Emacs format.

(define-key [S-tab] 'field-backward)

Do not use any of the abbreviated forms, except for simple "ascii" events where you can use a string.

Mouse Bindings

Unfortunately, Emacs uses mouse-2 while XEmacs uses button2. I haven't found a way around this, except to write conditional code.

  (if (string-match "XEmacs" emacs-version)
      (define-key map [button2] 'func)
    (define-key map [mouse-2] 'func))

News flash! XEMacs 19.15 and later understands the `mouse-2' keysyms.

Mode Menus

Use easymenu for defining major and minor mode menus.

Text Properties

Use text properties instead of overlays or extents, when possible.

Bundling

If you think your package has general interest, it will be useful to many more people if it gets included in the standard distribution. Contact rms (send mail to bug-gnu-emacs-request@prep.ai.mit.edu) about assigning copyright. Emacs has been harassed legally before by a producer of a commercial editor on copyright issues, so rms is now very careful about that. The XEmacs maintainers judge the risk of another legal threat as negligible, so they don't care about legal papers. Thus, if you make sure your package is acceptable to rms it will also be acceptable in XEmacs.

Unless you explicitly tell him not to, rms will reserve the right to make changes in the package once it is bundled with Emacs. This has the advantage of making Emacs feel more like a single application than like a collection of unrelated packages. However, it has the disadvantage that he (or other contributors) might introduce bugs or misfeatures in your package. If you feel strongly about this, make rms aware of this before donating the code. The XEmacs maintainers generally leave your code alone.

Why are there two Emacsen?

Hysterical reasons. See the public flames if you must know. Currently the largest problems is that Sun owns the copyright for large part of the code. It is copyleft, but they refuse to sign over the changes to the FSF. Some people think it is good to have an Emacs variant where you can contribute code without signing any papers. Feel free to disagree.

What can you do about it?

Nothing, really. Complain to Sun. The XEmacs developers are actively trying to make as much code as possible sharable between the two Emacsen, you may want to help them.

Per Abrahamsen <abraham@dina.kvl.dk>