Next: , Previous: , Up: Introduction  

Q1.3.6: How do I portably code for MULE/SXEmacs?

MULE has evolved rapidly over the last few years, and the original third party patch (for GNU Emacs 19), GNU Emacs 20+, and XEmacs 20+ have quite different implementations. The APIs also vary although recent versions of XEmacs have tended to converge to the GNU Emacs standard.

MULE implementations are going to continue to evolve. Both GNU Emacs and XEmacs are working hard on Unicode support, which will involve new APIs and probably variations on old ones. For XEmacs 22, the old ISO 2022-based system for recognizing encodings will be replaced by a much more flexible system, which should improve accuracy of automatic coding detections, but will also involve new APIs.

MORIOKA Tomohiko writes:

The application implementor must write separate code for these mule variants. [Please don’t hesitate to report these variants to us; they are not, strictly speaking, bugs, but they give third-party developers the same kind of creepy-crawly feeling. We’ll do what we can. – Ed.]

MULE and the next version of Emacs are similar but the symbols are very different—requiring separate code as well.

Namely we must support 3 kinds of mule variants and 4 or 5 or 6 kinds of emacs variants... (;_;) I’m shocked, so I wrote a wrapper package called emu to provide a common interface. [There is an XEmacs package of APEL which provides much more comprehensive coverage. Be careful, however; APEL has problems of its own. – Ed.]

I have the following suggestions about dealing with mule variants:

Following is a sample to distinguish mule variants: 

(if (featurep 'mule)
    (cond ((boundp 'MULE)
           ;; for original Mule
           )
          ((string-match "XEmacs" emacs-version)
           ;; for XEmacs with Mule
           )
          (t
           ;; for next version of Emacs
           ))
  ;; for old emacs variants
  )

Next: , Previous: , Up: Introduction