General architecture
Almost all of the functionality in Emacs, including basic editing operations such as the insertion of characters into a file, is achieved through functions written in a dialect of the Lisp programming language. The dialect used in GNU Emacs is known as Emacs Lisp (Elisp), and was developed expressly to port Emacs to GNU and Unix. The Emacs Lisp layer sits atop a stable core of basic services and platform abstraction written in the C programming language, which enables GNU Emacs to be ported to a wide variety of operating systems and architectures without modifying the implementation semantics of the Lisp system where most of the editor lives. In this Lisp environment, variables and functions can be modified with no need to rebuild or restart Emacs, with even newly redefined versions of core editor features being asynchronously compiled and loaded into the live environment to replace existing definitions. Modern GNU Emacs features both bytecode and native code compilation for Emacs Lisp.
All configuration is stored in variables, classes, and data structures, and changed by simply updating these live. The use of a Lisp dialect in this case is a key advantage, as Lisp syntax consists of so-called symbolic expressions (or sexprs), which can act as both evaluatable code expressions and as a data serialisation format akin to, but simpler and more general than, well known ones such as XML, JSON, and YAML. In this way there is little difference in practice between customising existing features and writing new ones, both of which are accomplished in the same basic way. This is operatively different from most modern extensible editors, for instance VS Code, in which separate languages are used to implement the interface and features of the editor and to encode its user-defined configuration and options. The goal of Emacs' open design is to transparently expose Emacs' internals to the Emacs user during normal use in the same way that they would be exposed to the Emacs developer working on the git tree, and to collapse as much as possible of the distinction between using Emacs and programming Emacs, while still providing a stable, practical, and responsive editing environment for novice users.
The main text editing data structure is the buffer, a memory region containing data (usually text) with associated attributes. The most important of these are:
The point: the editing cursor;
The mark: a settable location which, along with the point, enables selection of
The region: a conceptually contiguous collection of text to which editing commands will be applied;
The name and inode of the file the buffer is visiting (if any);
The default directory, where any OS-level commands will be executed from by default;
The buffer's modes, including a major mode possibly several minor modes
The buffer encoding, the method by which Emacs represents buffer data to the user;
and a variety of buffer local variables and Emacs Lisp state.
Modes, in particular, are an important concept in Emacs, providing a mechanism to disaggregate Emacs' functionality into sets of behaviours and keybinds relevant to specific buffers' data. Major modes provide a general package of functions and commands relevant to a buffer's data and the way users might be interacting with it (e.g. editing source code in a specific language, editing hex, viewing the filesystem, interacting with git, etc.), and minor modes define subsidiary collections of functionality applicable across many major modes (such as auto-save-mode). Minor modes can be toggled on or off both locally to each buffer as well as globally across all buffers, while major modes can only be toggled per-buffer. Any other data relevant to a buffer but not bundled into a mode can be handled by simply focussing that buffer and live modifying the relevant data directly.
Any interaction with the editor (like key presses or clicking a mouse button) is realized by evaluating Emacs Lisp code, typically a command, which is a function explicitly designed for interactive use. Keys can be arbitrarily redefined and commands can also be accessed by name; some commands evaluate arbitrary Emacs Lisp code provided by the user in various ways (e.g. a family of eval- functions, operating on the buffer, region, or individual expression). Even the simplest user inputs (such a printable characters) are effectuated as Emacs Lisp functions, such as the self-insert-command, bound by default to most keyboard keys in a typical text editing buffer, mapping the key used to call it into the associated locale-defined character.
For example, pressing the f key in a buffer that accepts text input evaluates the code (self-insert-command 1 ?f), which inserts one copy of the character constant ?f at point. The 1, in this case, is determined by what Emacs terms the universal argument: all Emacs command code accepts a numeric value which, in its simplest usage, indicates repetition of an action, but in more complex cases (where repetition doesn't make sense) can yield other behaviours. These arguments may be supplied via command prefixes, such as Control+u 7 f, or more compactly Meta+7 f, which expands to (self-insert-command 7 ?f). When no prefix is supplied, the universal argument is 1: every command implicitly runs once, but may be called multiply, or in a different way, when supplied with such a prefix. Such arguments may also be non-positive where it makes sense for them to be so - it is up to the function accepting the argument to determine, according to its own semantics, what a given number means to it. One common usage is for functions to perform actions in reverse simply by checking the sign of the universal argument, such as a sort command which sorts in obverse by default and in reverse when called with a negative argument, using the absolute value of its argument as the sorting key (e.g. -7 sorting in reverse by column index (or delimiter) 7), or undo/redo, which are simply negatives of each other (traversing forward and backward through a recursive history of diffs by some number of steps at a time).
Because of its relatively large vocabulary of commands, Emacs features a long-established command language, to concisely express the keystrokes necessary to perform an action. This command language recognises the following shift and modifier keys: Ctrl, Alt, ⇧ Shift, Meta, Super, and Hyper. Not all of these may be present on an IBM-style keyboard, though they can usually be configured as desired. These are represented in command language as the respective prefices: C-, A-, S-, M-, s-, and H-. Keys whose names are only printable with more than one character are enclosed in angle brackets. Thus, a keyboard shortcut such as Ctrl+Alt+⇧ Shift+F9 (check dependent formulas and calculate all cells in all open workbooks in Excel) would be rendered in Emacs command language as C-A-S-<f9>, while an Emacs command like Meta+s f Ctrl+Meta+s (incremental file search by filename-matching regexp), would be expressed as M-s f C-M-s. Command language is also used to express the actions needed to invoke commands with no assigned shortcut: for example, the command scratch-buffer (which initialises a buffer in memory for temporary text storage and manipulation), when invoked by the user, will be reported back as M-x scra <return>, with Emacs scanning the namespace of contextually available commands to return the shortest sequence of keystrokes which uniquely lexicate it.
Because Emacs predates modern standard terminology for graphical user interfaces, it uses somewhat divergent names for familiar interface elements. Buffers, the data that Emacs users interact with, are displayed to the user inside windows, which are tiled portions of the terminal screen or the GUI window, which Emacs refers to as frames; in modern terminology, an Emacs frame would be a window and an Emacs window would be a panel or split. Depending on configuration, windows can include their own scroll bars, line numbers, sometimes a 'header line' typically to ease navigation, and a mode line at the bottom (usually displaying buffer name, the active modes and point position of the buffer among others). The bottom of every frame is used for output messages (then called 'echo area') and text input for commands (then called 'minibuffer').
In general, Emacs display elements (windows, frames, etc.) do not belong to any specific data or process. Buffers are not associated with windows, and multiple windows can be opened onto the same buffer, for example to track different parts of a long text side-by-side without scrolling back and forth, and multiple buffers can share the same text, for example to take advantage of different major modes in a mixed-language file. Similarly, Emacs instances are not associated with particular frames, and multiple frames can be opened displaying a single running Emacs process, e.g. a frame per screen in a multi-monitor setup, or a terminal frame connected via ssh from a remote system and a graphical frame displaying the same Emacs process via the local system's monitor.
Just as buffers don't require windows, running Emacs processes do not require any frames, and one common usage pattern is to deploy Emacs as an editing server: running it as a headless daemon and connecting to it via a frame-spawning client. This server can then be made available in any situation where an editor is required, simply by declaring the client program to be the user's EDITOR or VISUAL variable. Such a server continues to run in the background, managing any child processes, accumulating stdin from open pipes, ports, or fifos, performing periodic or pre-programmed actions, and remembering buffer undo history, saved text snippets, command history, and other user state between editing sessions. In this mode of operation, Emacs overlaps the functionality of programs like screen and tmux.
Because of its separation of display concerns from editing functionality, Emacs can display roughly similarly on any device more complex than a dumb terminal, including providing typical graphical WIMP elements on sufficiently featureful text terminals - though graphical frames are the preferred mode of display, providing a strict superset of the features of text terminal frames.
