Internally Polymode uses indirect buffers to implement inner spans of different modes. Each inner major mode within a polymode buffer has its own indirect buffer associated with it. Host mode lives in the base buffer. Therefore, switching modes in Polymode is as fast as switching emacs buffers because it never re-installs major modes like most of other MMM frameworks do. Dave Love's [multi-mode.el](http://www.loveshack.ukfsn.org/emacs/multi-mode.el) gets full credit for this idea. By _sibling buffers_ we mean base or indirect buffers which are shared with the current buffer. ## Terminology - _**span**_ is a contiguous and homogeneous region of text of the same Emacs major mode. There are 4 types of spans: head, body, tail and host.
All spans are closed on the left and open on the right. For example, a span spanning [3, 5) contains character at position 3 but not at position 5. This is consistent with how emacs' functions deal with text properties. - _**chunk**_ is a contiguous region that consists of one or more _spans_. There are two major types of chunks: - _**host chunks**_ which contain only one span in the host major mode. - _**inner chunks**_ which commonly consists of head, body and tail, where body is of some other mode than host.
- _**polymode**_ means one of the following: 1. a _sum_ of related functionality available in emacs buffers 2. _function_ which installs a bunch of functionality into emacs buffers.
Polymodes can be used like any other emacs major mode (for example placed in `auto-mode-alist`), or like a minor mode in order to install functionality on top of an existing emacs mode.
3. an _object_ of class `pm-polymode` which holds the configuration for the polymode. - _**chunkmode**_, and the more specific _**hostmode**_ and _**innermode**_ mean either: 1. a _sum_ of related functionality in host and inner chunks 2. configuration _objects_ derived from `pm-chunkmode` class (`pm-host-hostmode`, `pm-inner-innermode`, `pm-inner-auto-chunkmode`). ## Configuration Host and inner chunks are configured through _objects_ derived from `pm-chunkmode` class and are generically referred to as "chunkmodes". These objects have named of the form `poly-XYZ-hostmode` and `poly-XYZ-innermode` and are refereed to as `hostmodes` and `innermodes` respectively. Polymodes are configured through _objects_ of class `pm-polymode` which are named with `poly-XYZ-polymode` scheme where `XYZ` is the same as in the polymode function `poly-XYZ-mode`. During initialization of the polymodes the `poly-XYZ-polymode` object is cloned and stored in a buffer-local variable `pm/polymode`. This object is shared across all sibling buffers. `Chunks` and `chunkmodes` are different concepts. Chunk is a fragments of text and there might be multiple chunks of the same mode within a buffer. In contrast, there is only one chunkmode of some type per buffer and the "behavior" in each chunk is determined by the chunkmode. ## Class Hierarchy Polymode package uses `eieio` to represent its objects. The root class for all polymode classes is `eieio-instance-inheritor` which provides prototype based inheritance. This means that objects instantiated from polymode classes can be cloned in order to dynamically create a hierarchy of customizable objects. Instance inheritance (or prototype inheritance) means that if you change a slot of a parent object, all of the children and grand-children of the object will inherit the new value unless they explicitly overwrite that slot. There are a bunch of such objects already defined, you can check those in `polymodes`, `poly-hostmodes` and `poly-innermodes` customization groups. Polymode class hierarchy: ``` +--eieio-instance-inheritor +--pm-root +--pm-polymode +--pm-chunkmode | +--pm-inner-chunkmode | | +--pm-inner-auto-chunkmode | +--pm-host-chunkmode +--pm-weaver | +--pm-shell-weaver | +--pm-callback-weaver +--pm-exporter +--pm-shell-exporter +--pm-callback-exporter ``` *Using Help with EIEIO:* Each `eieio` class has a corresponding constructor whose docstring contains a complete description of the class. ## General Naming Conventions User facing functionality is named with `polymode-` prefix. Polymodes are named with `poly-XYZ-mode` convention. Host, inner and polymode configuration objects are named `poly-XYZ-hostmode`, `poly-XYZ-innermode` and `poly-name-polymode`. Classes, methods and developer-oriented API have `pm-` prefix.