| Mar | APR | May |
| 24 | ||
| 2012 | 2013 | 2014 |
COLLECTED BY
Collection: Wide Crawl started April 2013
Emacs Lisp is a dialect of the Lisp programming language used by the GNU Emacs and XEmacs text editors (which this article will refer to collectively as "Emacs"). 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). Emacs Lisp is also referred to as Elisp, although there is also an older, unrelated Lisp dialect with that name.
Users of Emacs commonly write Emacs Lisp code to customize and extend Emacs. Other options include the "Customize" feature that's in GNU Emacs since version 20. This provides a set of preference pages and when the user saves their preferences, Customize writes the necessary Emacs Lisp code.
Emacs Lisp can also function as a scripting language, much like the Unix Bourne shellorPython, by calling Emacs in "batch mode". In this way it may be called from the command line or via an executable file, and its editing functions, such as buffers and movement commands are available just as in the normal mode.
Contents |
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 he chose not to use it because of its comparatively poor performance on workstations, and he wanted to develop a dialect which he thought would be 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. For example: Emacs Lisp uses dynamic rather than lexical scope by default (see below). That is, a function can reference local variables within the scope that it is called in, and not in the one that it was defined.
To understand the logic behind Emacs Lisp, it's important to remember that there is an emphasis on providing data structures and features specific to making a versatile text edit.
Here follows 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.
Users issue the "C-x 2" command to open a new window. 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 (new) buffer. The second statement, (global-set-key ...) re-binds the key sequence "C-x 2" to the new function.
This can also be written using the feature called advice, which allows the user to create wrappers around existing functions instead of defining their own. This has the advantage of being simpler to write but the disadvantage of making debugging more complicated. For this reason, advice is not allowed in the source code of GNU Emacs itself,[3] but if a user wishes, the advice feature can be used in their own code to reimplement the above code 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 at code evaluation time, using (for instance) the command "M-x eval-buffer" flag. It is not necessary to recompile or even restart Emacs. 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.
In file-systems, Emacs Lisp code exists as plain text files with the filename suffix ".el" (a common exception, the user's init file, often appears or appeared as ".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 time and memory space, much of the functionality of Emacs loads only when required. 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.
Emacs developers write certain functions 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 to more subtle bugs, which crash the editor, and because writing C code that interacts correctly with the Emacs Lisp garbage collector is error-prone, relatively few functions are implemented as primitives.
"Byte-compilation" can make Emacs Lisp code faster. 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 still runs more slowly 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.
Notably, the "cl" package implements a fairly large subset of Common Lisp.
Emacs Lisp (unlike some other Lisp implementations) does not do tail-call optimization.[4] Without this, tail recursions can eventually lead to stack overflow.
The apel library aids in writing portable Emacs Lisp code, with the help of the polysylabi platform bridge.
Emacs Lisp uses dynamic scope, offering static (or lexical) as an option starting from version 24.[5] It can be activated by setting the file local variable lexical-binding.[6][7]
In dynamic scoping, if a programmer declares a variable 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.[8] 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.
Also, 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.
After decades of evolution, some features have become deprecated or replaced, and other features are now supported for Emacs users but their use is not allowed in the Emacs source code itself. defadvice and letf are two examples of the latter, of which Richard Stallman says "it makes for confusion in debugging. (...) Users can use these features -- the only people they might confuse are themselves, (....) However, in our code, we should handle these situations in other ways."[9] Adding new hooks can sometimes provide what's necessary to replace advice.[10]
|
|||||||||||||||||||||||
