1. Introduction

XEmacs is a powerful, extensible editor. The traditional way of extending the functionality of XEmacs is to use its built-in Lisp language (called Emacs Lisp). However, while Emacs Lisp is a full programming language and capable of extending XEmacs in more ways than you can imagine, it does have its disadvantages.

Firstly, Emacs Lisp has run-time type information, bounds checking on array accesses, circularity checking on processing of Lisp lists, garbage collection of allocated memory, and a well-defined and relatively user-friendly implicit conversion between external text encodings and its internal encoding. None of these features exist in C, and all of them have a necessary run-time cost.

The XEmacs implementation of Emacs Lisp uses a bytecode interpreter, which is necessarily slower than native code, given it is stack-oriented and has limited use of registers. However, Andrea Corallo demonstrated in 2021 when he implemented native compilation of Emacs Lisp on GNU Emacs that the speed advantage of compilation of Emacs Lisp to native code over bytecode is not that pronounced, almost certainly for the reasons listed above. C (or in theory Rust) will always have a speed advantage over Emacs Lisp.

Secondly, Emacs Lisp (or Lisp in general) is not a very common programming language, except for limited circles in the computer industry. C, while it is not a popular as it once was, is a more commonly known language, and there are many other languages that explicitly chose to stay close to C in their syntax and even library functions, which means the barrier to entry for C programming is a little lower than for Lisp programming.

This manual describes a way of extending XEmacs, by using dynamically loadable modules (also known as dynamically loadable libraries (DLLs), dynamic shared objects (DSOs) or just simply shared objects), which can be written in C or C++ and loaded into XEmacs at any time. I sometimes refer to this technology as CEmacs, which is short for C Extensible Emacs.

XEmacs modules are configured into and installed with XEmacs by default on all systems that support loading of shared objects. From a user’s perspective, the internals of XEmacs modules are irrelevant. All a user will ever need to know about shared objects is the name of the shared object when they want to load a given module. From a developer’s perspective though, a lot more is provided.

• Of primary interest is the ellcc program. This is written in XEmacs Lisp, since that is a portable scripting language available wherever XEmacs is. It is intended to abstract compiler specific characteristics from the developer. This program is called to compile and link all objects that will make up the final shared object, and accepts all common C compiler flags. ellcc also sets up the correct environment for compiling modules by enabling any special compiler modes (such as PIC mode), setting the correct include paths for the location of XEmacs internal header files etc. The program will also invoke the linker correctly to create the final shared object which is loaded into XEmacs.
• CEmacs also makes all of the relevant XEmacs internal header files available for module authors to use. This is often required to get data structure definitions and external variable declarations. The header files installed include the module specific header file ‘emodules.h’. Due to the nature of dynamic modules, most of the internals of XEmacs are exposed. See (internals)Top section ‘Top’ in XEmacs Internals Manual, for a more complete discussion on how to extend and understand XEmacs. All of the rules for C modules are discussed there.
• Part of the XEmacs distribution is a set of sample modules. These are not installed when XEmacs is, but remain in the XEmacs source tree. These modules live in the directory ‘modules’, which is a sub-directory of the main XEmacs source code directory. Please look at the samples carefully, and maybe even use them as a basis for making your own modules. Most of the concepts required for writing extension modules are covered in the samples.
• Last, but not least is this manual. This can be viewed from within XEmacs, and it can be printed out as well. It is the intention of this document that it will describe everything you need to know about extending XEmacs in C. If you do not find this to be the case, please contact the author(s).

The rest of this document will discuss the actual mechanics of XEmacs modules and work through several of the samples. Please have the XEmacs Internals Manual close to hand and check it regularly. The concepts there apply to all modules. This document may have some overlap, but it is the Internals Manual which should be considered the final authority. It will also help a great deal to look at the actual XEmacs source code to see how things are done.

This document was generated on September 26, 2026 using texi2html 1.82.