This document covers the general structure of RSyntaxTextArea. While it tries to be very thorough, you should probably have a basic understanding of the Swing text package. For a high level overview of that topic, visit Using Text Components and its sub-articles.

RSyntaxTextArea is actually built on RTextArea. RTextArea is a simple subclass of the standard JTextArea that adds many features it lacks that are typically found in text components:

• Insert/Overwrite modes
• A customizble context menu with the standard editing options.
• Undo and redo
• Hard or soft (emulated with spaces) tabs
• Macro support

It does not know anything about syntax highlighting or features that are specific to code editors. Its code can be found in the org.fife.ui.rtextarea package.

RSyntaxTextArea is of course the main class of the library. Most consumers will simply instantiate one of these, usually placing it in an RTextScrollPane for line numbers and/or code folding. It is a simple extension of JTextArea that adds properties for syntax highlighting-specific features - color schemes, braecket matching, code folding, etc. Most of he dirty work is actually done in other classes.

Key strokes are mapped to Actions to handle user input. The mappings themselves are defined in RSyntaxTextAreaDefaultInputMap, and its parent class, RTADefaultInputMap. In those classes you can easily see and edit all keystrokes RSTA recognizes. For any printable character not listed, that character is simply inserted into the document.

The Actions that get executed are defined in RSyntaxTextAreaEditorKit, and its parent class RTextAreaEditorKit.

As RsyntaxTextArea is a standard Swing text component implementation, its model is stored in a Document. The RSyntaxDocument class extends PlainDocument and adds the smarts required to parse and syntax highlight code for arbitrary programming languages.

Syntax highlighting is done by implementations of the TokenMaker interface. RSyntaxDocument has a TokenMaker member that it uses to parse its text content, to determine how to highlight it. All built-in TokenMakers are found in the org.fife.ui.rsyntaxtextarea.modes package. Most, if not all, of the standard TokenMakers are also built using JFlex, both for performance and for ease of maintenance. However, one is not precluded from creating a TokenMaker for a new language "by hand." For a discussion of adding syntax highlighting support for a new language, see Adding Custom Synax Highlighting.

Code folding is done by implementations of the FoldParser interface. When folding is enabled, an RSyntaxTextArea keeps an instance of a FoldParser (indirectly), and calls into it whenever its Document is modified, so any changes in the fold structure can be identified.

The fold parsing is actually done by a FoldManager, though applications should never have a need to access this class directly. A FoldManager registers itself as a Parser on an RSTA instance, and listens for DocumentEvents. It only re-parses the document for new folds when it is notified to do so, which means the user has to "pause" for a short amount of time while typing for folds to be re-evaluated. This is done for performance reasons, and is typical of code editors, so it is a non-issue. See Adding a Parser to RSyntaxTextArea for more information on how this mechanism works.