What is a folding editor?

Most folding capabilities in editors such as GNU Emacs and most folding editors such as Origami and fe, are inspired by the Inmos Transputer Development System. After several years, folding/outlining capabilities in text editors are not as exotic as they used to be, but they are still far from being well known. This document explains what "folding" is all about.

A folding editor extends the principle of tree structured directories to editing text files. This allows the simultaneous display of large amounts of text by folding sections of text away behind a descriptive heading. This results in a tree structure very similar to a subdirectory structure of, for example, UNIX. By suitable structuring of a text it should be possible, in most circumstances, to ensure that no display exceeds a single screen at any time. To access text that is folded away, you open the fold, in which case the contents are displayed in context of the surrounding text. The advantage of this system is that it eliminates the need for seemingly endless paging through long files to find the section of interest, allowing you to move down the tree structure, following the (hopefully) descriptive headers to locate the text you require.

As an example, the fe reference manual looks like this at the top level (e.g. immediately after starting fe):

.... Macros
.... Title
.H 1 "Copyright and usage conditions" ...
.H 1 "First things first" ...
.H 1 "Files and Buffers" ...
.H 1 "Arguments" ...
.H 1 "Moving the cursor" ...
.H 1 "Editing" ...
.H 1 "Regions and the kill ring" ...
.H 1 "Folding" ...
.H 1 "Search and replace" ...
.H 1 "Modes and variables" ...
.H 1 "Macros" ...
.H 1 "Windows" ...
.H 1 "Shell commands" ...

You currently see a file of almost 700 lines, but its structure is easy to recognize. Opening the "Folding" chapter leads to the following display:

.... Macros
.... Title
.H 1 "Copyright and usage conditions" ...
.H 1 "First things first" ...
.H 1 "Files and Buffers" ...
.H 1 "Arguments" ...
.H 1 "Moving the cursor" ...
.H 1 "Editing" ...
.H 1 "Regions and the kill ring" ...
.H 1 "Folding" {{{
.VL \n(Pi
.... M-C-@                -- fold region
.... C-u                  -- unfold
.... C-o                  -- open fold
.... C-c                  -- close fold
.LE
.}}}
.H 1 "Search and replace" ...
.H 1 "Modes and variables" ...
.H 1 "Macros" ...
.H 1 "Windows" ...
.H 1 "Shell commands" ...

At this point, you could open the nested folds until actual text is reached. The fold marks are stored in the text as normal lines, but they are put into comments for whatever tool processes the files. Folds for troff look like this:

.H 1 "Folding" \"{{{

As you can imagine, folds for C are embedded in C comments:

int main(int argc, char *argv[]) /*{{{*/

Experience has shown that folding supports more modular and well commented source code. The code has a better structure, because the structure is obvious. Editing becomes more efficient, because moving to a particular place in the code is very easy and cut&paste facilities can be used on whole folds which makes reorganizing the structure easy. Folding is suitable for any structured documents, be it source code or regular texts for troff, LaTeX etc.