3. Basic concepts and terminology

In this section we list and describe several concepts often used in this manual without a further reference.

file

Files is a collections of trees (possibly acompanied with some meta data common to all trees). Although the in-memory representation of a file has always the same form, its “physical representation” (called format) may vary. The part of TrEd program responsible for reading and writing files in a specific format is called a I/O Backend. Depending on a format, files may differ in some features.

I/O backend

I/O backend is a module of TrEd responsible for reading and writing files in some particular data format. Thus, adding support for a new data format only requires writing a corresponding I/O backend. Different data formats not only represent the data (trees, nodes, meta data) differently, but often differ in the ability to interchange data with other I/O backends because of the nature of the data. For example, while some I/O backends are rather generic, other are tightly bound to the actual content of the data (hence loading a file using one I/O backend and saving it in another may not work as expected in all cases). Nonetheless, most of the I/O backends used in TrEd are able to read the data and save them back without any loss of information. Detailed discussion of I/O backends can be found in Section 15, “I/O backends”.

tree

A trees in this context is a rooted oriented cycle-free graph of nodes. In other words: it is a finite ordered set of objects called nodes (sometimes, but not in this manual, also called verteces), each of the nodes but one is connected to another node called it's parent-node. This connection is called an edge. Such a structure is then called a tree if edges never form a cycle, i.e. by following an edge-path (e.g. a sequence of adjacent edges leading from a node to its parent-node) we never return to the node where we started. There is exactly one node without a parent-node, called the root of the tree. Every edge-path in the tree leads to this node. If A is a parent-node of B, then B is a child-node of A. Nodes having the same node as their parent-node are called siblings. In TrEd's internal representation of a tree, there are the following additional links between nodes:

  • a link from a parent-node to one of its child-nodes (usually but not necessarily this is the first of its child-nodes in the linear ordering of the tree). This child-node is called the first-son of the parent-node.

  • First son is linked with its next sibling (if any), called it's right-sibling node (or lbrother). This sibling is again connected to another sibling, etc, so that all siblings are connected and this connection contains no cycle. Hence child-nodes of each node form a (possibly empty) chain originating on the first-son and connecting all its siblings one after another. The last sibling in the chain is called the last-sibling or last-son.

  • For easier tree traversal, nodes in TrEd also contain link representing a reversed version of the previous “right-sibling” relation, called left-sibling (or lbrother). So, if a node A is the right-sibling of B, then B is the left-sibling of A.

node

We have already describe a node as an object occuring in a tree and possibly connected to other nodes in the tree. Apart from that, every node may be associated with some data represented in form of an attribute-value structure (AVS or feature-structure if you like). Each members of this structure (also called an attribute) has a name and value. Each name may occure in AVS only once. The names of node's attributes and types of their values are file-specific (or in some cases I/O-backend specific). Generally, a value of an attribute may be of one of the following types (it must be noted that not all of the types are supported by the I/O backends equally):

  • string

  • enumerated type (a string value from a pre-defined list)

  • flat” list of values of one of the above types, i.e. a string of |-separated items. This type is used e.g. by FS-backend.

  • constant (usually not very useful, but sometimes handy)

  • attribute-value stucture (implemented as a Perl hash reference, fully supported by PML-backend and partially emulated by FS-backend)

  • ordered list of values of any type except list (implemented as a Perl array reference of the Fslib::List class). Currently only supported by PML-backend.

  • unordered list of values of any type except list (implemented and supported likewise).

  • alternative of values of any type except alternative (implemented as a Perl array reference of the Fslib::Alt class). Alternative is very similar to unordered list but as long as it has only one single value, it is represented by that value (rather than a Fslib::Alt array reference containing that value). Alternatives are currently supported by PML-backend.

file-list

Files in TrEd are further organized into collections called file-lists. A file-list is basically a list of filenames of files belonging to the collection.

view

A view is the part of TrEd window where a tree is displayed. TrEd allows for multiple views (created by splitting a view in half either along the horizontal or vertical axis). Always, one of the views is focused. This view is called the active view (also the current view). All commands related to a file, tree and node usually only apply to the active view (or more specifically, to the objects it displays). The active view is visually distinguishable from the other views by its thick black border. Optionally, inactive views may also be stippled (see StippleInactiveWindows). Views can display trees from one file but also from several unrelated files. It is also possible to display a single tree in several views simultaneously. Each view is associated with a file-list and a in-memory representation of a single file from that file-list (in case of the active view called the current file-list and the current file).

active (or current) node

The active node plays a similar role to that of a cursor in a text editor. Each view remembers its active node. In general, if we refer to the active or current node, we usually mean the active node of the active view. In the default setup, the active node is by default visually differentiated from other nodes by its red color (other nodes are displayed as yellow or black). However, it must be noted that a stylesheet can (and often does) change the coloring of the tree, including definin its own way to distinguish the active node.

macro

TrEd by default offers only a small set of fundamental and generic tree-editing commands. Commands specific to certain purpose or data are typically implemented as user-defined macros. A macro is a small program (more specifically a Perl subroutine), typically associated with a keyboard shortcut or a menu item. See Section 14, “User Macros” for details.

hook

Hooks are similar to macros but they are called indirectly by TrEd rather directly by the user, although they also in a way response to a particular event or action performed by the user. For example, every time the user performs an action resulting in a file being opened, TrEd tries to locate and call a user-defined function named file_opened_hook in the current binding context (described below). See Section 14.9, “Hooks: automatically executed macros” for details.

binding context

Macros serving similar purpose and often related to some specific data may be organized to sets called binding context. Each view is associated with a binding context (called the current context) and the user may easilly switch from one context to another. If the user presses a keyboard shortcut, TrEd tries to find a binding for that shortcut in the current binding context. If it fails, tries the same with a default context called TredMacro. Similar lookup applies when the user performs an action which requires a hook to be called. See Section 14.10, “Using different sets of macros in different situations” for details.

stylesheet

A stylesheet is a set of rules (called patterns) modifying the default appearance of trees in a view. Each view initially uses a stylesheet provided by the data file (which may be empty), but the user may instruct the view to use another stylesheet. The same tree may be viewed simultaneously in different views with completely different stylesheets. If a very complex visual presentation is required, stylesheet rules may be accompanied by some further presentational code defined in a node_style_hook. For more information see Section 9, “Customizing Tree Appearance: Stylesheets”.