Emacs Lisp

From Wikipedia, the free encyclopedia

Jump to: navigation, search

Emacs Lisp is a dialect of the Lisp programming language used by the GNU Emacs and XEmacs text editors (which will be collectively referred to as Emacs in this article). It is used for implementing most of the editing functionality built into Emacs, the remainder being written in C (as is the Lisp interpreter itself). Users of Emacs commonly write Emacs Lisp code to customize and extend Emacs.

Emacs Lisp can also be used as a scripting language, much like the Unix Bourne shell, Perl, Python, scsh, or GNU Guile. Just as with those languages, it may be called from the command line or via an executable file. Its editing functions, such as buffers and movement commands, complement the features of Lisp and work in batch mode.

Emacs Lisp is sometimes called Elisp, at the risk of confusion with an older unrelated Lisp dialect with the same name. In terms of features, it is closely related to the Maclisp dialect, with some later influence from Common Lisp [1]. It supports imperative and functional programming methods. Richard Stallman chose Lisp as the extension language for his rewrite of Emacs (the original used TECO as its extension language) because of its powerful features, including the ability to treat functions as data. Unlike Common Lisp, Scheme existed at the time Stallman was rewriting Gosling Emacs into GNU Emacs, but it was not used because of Scheme's then-poor performance on workstations, and he had to develop a dialect more easily optimized.[2]

The Lisp dialect used in Emacs differs substantially from the more modern Common Lisp and Scheme dialects commonly used for applications programming. One of the major differences is that Emacs Lisp uses dynamic rather than lexical scope by default. That is, local variables in a calling function can be referenced from a called function without passing pointers or references.

Writing Emacs Lisp is not the only method of customizing GNU Emacs. Since version 20, GNU Emacs has included a "Customize" facility which allows users to set common customization variables through a graphical interface. "Customize" works by writing Emacs Lisp code for the user, and is limited to relatively simple customizations. Not every user needs the full degree of extensibility offered by Emacs; those that do can write their own Emacs Lisp code.

Contents

[edit] Example

Here is a simple example of an Emacs extension written in Emacs Lisp. In Emacs, the editing area can be split into separate areas called windows, each displaying a different buffer. A buffer is a region of text loaded into Emacs' memory (possibly from a file) which can be saved into a text document.

The user command for opening a new window is "C-x 2". This runs the Emacs Lisp function split-window-vertically. Normally, when the new window appears, it displays the same buffer as the previous one. Suppose we wish to make it display the next available buffer. In order to do this, the user writes the following Emacs Lisp code, in either an existing Emacs Lisp source file or an empty Emacs buffer:

(defun my-split-window-func ()
    (interactive)
    (split-window-vertically)
    (set-window-buffer (next-window) (other-buffer)))
 
(global-set-key "\C-x2" 'my-split-window-func)

The first statement, (defun ...), defines a new function, my-split-window-func, which calls split-window-vertically (the old window-splitting function), then tells the new window to display another buffer. The second statement, (global-set-key ...) re-binds the key sequence "C-x 2" to the new function.

However, there is an easier way to write this. Emacs Lisp has a powerful feature called advice, which allows the user to create wrappers around existing functions instead of defining their own. Using advice, the above code can be reimplemented as follows:

(defadvice split-window-vertically
    (after my-window-splitting-advice first () activate)
    (set-window-buffer (next-window) (other-buffer)))

This instructs split-window-vertically to execute the user-supplied code whenever it is called, before executing the rest of the function.

These changes take effect when the code is evaluated, using (for instance) the command "M-x eval-buffer". It is not necessary to recompile or even restart Emacs, which makes customizing Emacs very convenient. If the code is saved into the Emacs "init file" (usually a file named ".emacs" in the user's home directory), then Emacs will load the extension the next time it starts. Otherwise, the changes will be lost when the user exits Emacs.

[edit] Source code

Emacs Lisp code is stored as plain text, with the filename suffix ".el" (an exception being the user's init file, which is named ".emacs".) When the files are loaded, an interpreter component of the Emacs program reads and parses the functions and variables, storing them in memory. They are then available to other editing functions, and to user commands. Functions and variables can be freely modified and re-loaded.

In order to save memory space, much of the functionality of Emacs is not loaded until it is needed. Each set of optional features is implemented by a collection of Emacs code called a "library". For example, there is a library for highlighting keywords in program source code, and a library for playing the game of Tetris. Each library is implemented using one or more Emacs Lisp source files.

Certain functions are written in C. These are "primitives", also known as "built-in functions" or "subrs". Although primitives can be called from Lisp code, they can only be modified by editing the C source files and recompiling. In GNU Emacs, primitives are not available as external libraries; they are part of the Emacs executable. In XEmacs, runtime loading of such primitives is possible, using the operating system's support for dynamic linking. Functions may be written as primitives because they need access to external data and libraries not otherwise available from Emacs Lisp, or because they are called often enough that the comparative speed of C versus Emacs Lisp makes a worthwhile difference.

However, because errors in C code can easily lead to segmentation violations or more subtle bugs, crashing the editor, and writing C code that interacts correctly with the Emacs Lisp garbage collector is error-prone, relatively few functions are implemented as primitives.

[edit] Byte code

The performance of Emacs Lisp code can be further increased by "byte-compilation". Emacs contains a compiler which can translate Emacs Lisp source files into a special representation known as bytecode. Emacs Lisp bytecode files have the filename suffix ".elc". Compared to source files, bytecode files load faster, occupy less space on the disk, use less memory when loaded, and run faster.

Bytecode is still slower than primitives, but functions loaded as bytecode can be easily modified and re-loaded. In addition, bytecode files are platform-independent. The standard Emacs Lisp code distributed with Emacs is loaded as bytecode, although the matching source files are usually provided for the user's reference as well. User-supplied extensions are typically not byte-compiled, as they are neither as large nor as computationally intensive.

[edit] Language features

The "cl" package is notable for implementing a fairly large subset of Common Lisp.

Emacs Lisp uses dynamic, not static (or lexical), scope. If a variable is declared within the scope of a function, it is available to subroutines called from within that function. Originally, this was intended as an optimization; lexical scoping was still uncommon and of uncertain performance[3]. Dynamic scoping was also meant to provide greater flexibility for user customizations. However, dynamic scoping has several disadvantages. Firstly, it can easily lead to bugs in large programs, due to unintended interactions between variables in different functions. Secondly, accessing variables under dynamic scoping is generally slower than under lexical scoping. As a result, plans have been made to convert Emacs Lisp to lexical scoping, though this has not yet been done. The lexical-let macro in the "cl" package does provide effective lexical scope to Emacs Lisp programmers, but while `cl' is widely used, lexical-let is rarely used. Variables bound with lexical-let are never released, even if they are never used.[4]

Emacs Lisp does not do tail-call optimization[citation needed], which is done in many other Lisp implementations. Without this, tail recursions can eventually lead to stack overflow.

[edit] Footnotes

  1. ^ "GNU Emacs Lisp is largely inspired by Maclisp, and a little by Common Lisp. If you know Common Lisp, you will notice many similarities. However, many features of Common Lisp have been omitted or simplified in order to reduce the memory requirements of GNU Emacs. Sometimes the simplifications are so drastic that a Common Lisp user might be very confused. We will occasionally point out how GNU Emacs Lisp differs from Common Lisp." — from the "History" section of the "Introduction" to the Emacs Lisp Manual, as of Emacs 21
  2. ^ "So the development of that operating system, the GNU operating system, is what led me to write the GNU Emacs. In doing this, I aimed to make the absolute minimal possible Lisp implementation. The size of the programs was a tremendous concern. There were people in those days, in 1985, who had one-megabyte machines without virtual memory. They wanted to be able to use GNU Emacs. This meant I had to keep the program as small as possible." — from "My Lisp Experiences and the Development of GNU Emacs"
  3. ^ "Emacs Lisp uses dynamic scoping because simple implementations of lexical scoping are slow."[1]; "I asked RMS when he was implementing emacs lisp why it was dynamically scoped and his exact reply was that lexical scope was too inefficient."[2]
  4. ^ "Emacs Lisp"[3]

[edit] External links

Free software portal
Retrieved from "http://en.wikipedia.org/wiki/Emacs_Lisp"
Personal tools