
\chapter{General architecture of TeXmacs}

\section{Introduction}

The \TeXmacs\ program has been written in C++.
You need ¤g++¤ and the ¤makefile¤ utility in order to compile \TeXmacs.
Moreover, I developed a preprocessor ¤gencc¤,
which is used for the automatic creation of makefiles and
generic template expansions (like ¤genclass¤ but more powerful).
For more details, look in the ¤doc¤ subdirectory of ¤gencc¤.

Currently, the source (in the ¤src¤ directory) of
the \TeXmacs\ implementation has been divided into the following parts:
\begin{itemize}
  \item A set of basic and generic data structures in the ¤Basic¤ directory.
  \item Standard resources for \TeXmacs, such as {\TeX} fonts,
        languages, encodings and dictionaries, in the ¤Resource¤ directory.
  \item A documented graphical toolkit in the ¤Window¤ directory
        (although the documentation is a bit outdated).
  \item The extension language for \TeXmacs\ in the ¤Prg¤ directory.
  \item The typesetting part of the editor in the directory ¤src/Typeset¤.
  \item The editor in the directory ¤src/Edit¤.
  \item The \TeXmacs\ server in the directory ¤src/Server¤.
\end{itemize}
All parts use the data structures from ¤Basic¤.
The graphical toolkit depends on ¤Resource¤ for the {\TeX} fonts.
The extension language is independent from ¤Resource¤ and ¤Window¤.
The typesetting part depends on all other parts except from ¤Prg¤.
The main editor and the \TeXmacs\ server use all previous parts.

The \TeXmacs\ data are contained in the directory ¤edit¤
which corresponds to the \TeXmacs\ distribution without the source code.
Roughly speaking, we have the following kind of data
\begin{itemize}
  \item Font data in ¤fonts¤ (encodings, ¤.pk¤ files, etc.).
  \item Language data in ¤languages¤ (hyphenation patterns,
        dictionaries, etc.).
  \item Document styles in ¤style¤.
  \item Initialization and other \scheme\ programs in ¤progs¤.
\end{itemize}
The directory ¤misc¤ contains some miscellaneous data
like the edit icon (¤misc/pixmaps/edit.xpm¤).

\section{Intern representation of texts}

{\TeXmacs} represents all texts by trees (for a fixed text,
the corresponding tree is called the \tmdef{edit tree}).
The nodes of such a tree are labeled by standard \tmdef{operators}
which are listed in ¤Typeset/data.gen.h¤ and ¤Typeset/data/data.gen.cc¤.
The labels of the leaves of the tree are strings, which are either invisible
(such as lengths or macro definitions), or visible (the real text).

The meaning of the text and the way it is typeset essentially depends
on the current environment. The environment mainly consists of
a relative hash table of type ¤rel_hashmap<string,tree>¤,
i.e. a mapping from the environment variables to their tree values.
The current language and the current font are examples of system
environment variables; new variables can be defined by the user.

\subsection{Text}

All text strings in {\TeXmacs} consist of sequences of either specific
or universal symbols. A specific symbol is a character,
different from ¤'\0'¤, ¤'<'¤ and ¤'>'¤.
Its meaning may depend on the particular font which is being used.
A universal symbol is a string starting with ¤'<'¤,
followed by an arbitrary sequence of characters different from
 ¤'\0'¤, ¤'<'¤ and ¤'>'¤, and ending with ¤'>'¤.
The meaning of universal characters does not depend on
the particular font which is used, but different fonts
may render them in a different way.

\subsection{The language}

The language of the text is capable performing a further semantic analysis
of a text phrase. At least, it is capable of splitting a phrase
up into \tmdef{words} (which are smaller phrases) and inform
the typesetter about the desired spaces between words and
hyphenation information. In the future, additional semantics
may be added into languages. For instance, spell checkers might
be implemented for natural languages and parsers for mathematical
formulas or programming languages.

\section{Typesetting texts}

Roughly speaking, the typesetter of \TeXmacs\ takes a tree on input and
produces a box, while accessing and modifying the typesetting environment.
The ¤box¤ class is multifunctional. Its principal method is used
for displaying the box on a post-script device (either the screen
or a printer). But it also contains a lot of typesetting information,
such as logical and ink bounding boxes, the positions of scripts, etc.

Another functionality of boxes is to convert between physical cursors
(positions on the screen) and logical cursors (paths in the edit tree).
Actually, boxes are also organized into a tree, which often simplifies
the conversion. However, because of macro expansions and line and page
breaking, the conversion routines may become quite intricate.
Notice also that, besides a horizontal and vertical position,
the physical cursor also contains an infinitesimal horizontal position.
Roughly speaking, this infinitesimal coordinate is used to give
certain boxes (such as color changes) an extra infinitesimal width.

\section{Making modifications in texts}

In ¤Edit/modify.gen.h¤ and ¤Edit/Modify¤ you find different routines
for modifying the edit tree. Modifications go in several steps:
\begin{enumerate}
  \item A certain input event triggers an action,
        such as ¤make_fraction¤, which intends to modify the edit tree.
  \item All modifications which ¤make_fraction¤ or its subroutines
        will make to the edit tree eventually break down to seven
        elementary modification routines, namely ¤assign¤, ¤insert¤,
        ¤remove¤, ¤split¤, ¤join¤, ¤ins_unary¤ and ¤rem_unary¤.
  \item Before performing the required modification,
        the elementary modification routine first notifies
        all views of the same text of the modification.
  \item On notification, each view updates several things,
        such as the cursor position. It also notifies
        the modification to the typesetter of the text,
        since the typesetter maintains a list of already
        typeset paragraphs.
  \item When all views have been notified of the modification,
        we really perform it.
  \item Each user action like a keystroke or a mouse click
        is responsable for inserting \tmdef{undo points}
        between sequences of elementary modifications.
        When undoing a modification, the editor will
        move to the previous undo point.
\end{enumerate}
