RSyntaxTextArea Design Overview
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.
RTextArea - The Foundation
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
RSyntaxTextArea - The Main Class!
is of course the main class of the library. Most consumers
will simply instantiate one of these, usually placing it in an
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
and its parent class
The Document Model
As RsyntaxTextArea is a standard Swing text component implementation, its
model is stored in a Document. The
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
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
, 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
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
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.