At last I understand what makes Leo special. It's Leo's DOM!
Leo's DOM (Document Object Model) consists principally of a DAG (Directed Acyclic Graph) of nodes. Nodes are real objects, consisting of:
- Headlines (labels or metadata),
- Body text (the node's primary data), and
- Secondary data: uA's (user Attribute objects) of arbitrary number and type.
- References to parent, sibling and child nodes.
Leo's DOM has surprising consequences:
Scripts can be applied to any node. This brings scripts to data.
Plugins and scripts can create their own kinds of @x trees that they interpret, process and modify as they see fit. But changing the meaning of data changes a DOM:
Plugins and scripts can easily and safely extend Leo's DOM.
Leo's nodes form a DAG: clones of a node may appear in many places within an outline. By grouping clones into views:
Any Leo outline can contain arbitrarily many views of the outline's data.
As an example of what Leo's DOM can do, my brother Speed Ream organizes Leo outlines so that the outlines themselves are queries. Speed's outlines don't contain queries, (parts of) Speed's outlines are the queries. Speed can search his Leo database without using any external database program.
In contrast, Emacs's DOM, if you could call it that, consists of buffers tied to files. You can't easily create long-lasting buffers because they intrude on the file system. Emacs buffers are mere strings, not objects--you can't distinguish parts of an Emacs buffer without parsing it, and you can't easily associate persistent data with Emacs buffers.