# Mode Definition Syntax

Edit modes are defined using XML, the eXtensible Markup Language; mode files have the extension `.xml`. XML is a very simple language, and as a result edit modes are easy to create and modify. This section will start with a short XML primer, followed by detailed information about each supported tag and highlighting rule.

Editing a mode or a mode catalog file within jEdit will cause the changes to take effect immediately. If you edit modes using another application, the changes will take effect after the Utilities > Troubleshooting > Reload Edit Modes command is invoked.

## An XML Primer

A very simple XML file (which also happens to be an edit mode) looks like so:

    <?xml version="1.0"?>

    <!DOCTYPE MODE SYSTEM "xmode.dtd">

    <MODE>
        <PROPS>
            <PROPERTY NAME="commentStart" VALUE="/*" />
            <PROPERTY NAME="commentEnd" VALUE="*/" />
        </PROPS>

        <RULES>
            <SPAN TYPE="COMMENT1">
                <BEGIN>/*</BEGIN>
                <END>*/</END>
            </SPAN>
        </RULES>
    </MODE>

Note that each opening tag must have a corresponding closing tag. If there is nothing between the opening and closing tags, for example `<TAG></TAG>`, the shorthand notation `<TAG />` may be used. An example of this shorthand can be seen in the `<PROPERTY>` tags above.

XML is case sensitive. `Span` or `span` is not the same as `SPAN`.

To insert a special character such as < or > literally in XML (for example, inside an attribute value), you must write it as an entity. An entity consists of the character's symbolic name enclosed within & and ;. The most frequently used entities are:

- `&lt;` - The less-than (<) character

- `&gt;` - The greater-than (>) character

- `&amp;` - The ampersand (&) character

For example, the following will cause a syntax error:

    <SEQ TYPE="OPERATOR">&</SEQ>

Instead, you must write:

    <SEQ TYPE="OPERATOR">&amp;</SEQ>

Now that the basics of XML have been covered, the rest of this section will cover each construct in detail.

## The Preamble and MODE tag

Each mode definition must begin with the following:

    <?xml version="1.0"?>
    <!DOCTYPE MODE SYSTEM "xmode.dtd">

Each mode definition must also contain exactly one `MODE` tag. All other tags (`PROPS`, `RULES`) must be placed inside the `MODE` tag. The `MODE` tag does not have any defined attributes. Here is an example:

    <MODE>
        ... mode definition goes here ...
    </MODE>

## The PROPS Tag

The `PROPS` tag and the `PROPERTY` tags inside it are used to define mode-specific properties. Each `PROPERTY` tag must have a `NAME` attribute set to the property's name, and a `VALUE` attribute with the property's value.

All buffer-local properties listed in may be given values in edit modes.

`contextInsensitive` - If true, the property indicates that a line can always be highlighted without taking care of the previous line. If activated, the syntax parsing will be much faster.

The following mode properties specify commenting strings:

- `commentEnd` - the comment end string, used by the Range Comment command.

- `commentStart` - the comment start string, used by the Range Comment command.

- `lineComment` - the line comment string, used by the Line Comment command.

When performing auto indent, a number of mode properties determine the resulting indent level:

- The line and the one before it are scanned for brackets listed in the `indentCloseBrackets` and `indentOpenBrackets` properties. Opening brackets in the previous line increase indent.

  If `lineUpClosingBracket` is set to `true`, then closing brackets on the current line will line up with the line containing the matching opening bracket. For example, in Java mode `lineUpClosingBracket` is set to `true`, resulting in brackets being indented like so:

      {
          // Code
          {
              // More code
          }
      }

  If `lineUpClosingBracket` is set to `false`, the line after a closing bracket will be lined up with the line containing the matching opening bracket. For example, in Lisp mode `lineUpClosingBracket` is set to `false`, resulting in brackets being indented like so:

      (foo 'a-parameter
          (crazy-p)
          (bar baz ()))
      (print "hello world")

- If the previous line contains no opening brackets, or if the `doubleBracketIndent` property is set to `true`, the previous line is checked against the regular expressions in the `indentNextLine` and `indentNextLines` properties. If the previous line matches the former, the indent of the current line is increased and the subsequent line is shifted back again. If the previous line matches the latter, the indent of the current and subsequent lines is increased.

  There are corresponding `unindentThisLine` and `unindentNextLines` properties which are checked also, for doing the reverse-indent operation on lines that match certain regular expressions.

  In Java mode, for example, the `indentNextLine` property is set to match control structures such as if, else, while, and so on.

  The `doubleBracketIndent` property, if set to the default of `false`, results in code indented like so:

      while(objects.hasNext())
      {
          Object next = objects.hasNext();
          if(next instanceof Paintable)
              next.paint(g);
      }

  On the other hand, settings this property to true will give the following result:

      while(objects.hasNext())
          {
              Object next = objects.hasNext();
              if(next instanceof Paintable)
                  next.paint(g);
          }

- `electricKeys`: characters listed here, when typed on a line, cause the current line to be re-indented. Notice that by default, pressing "Enter" does not re-indent the current line, only the new line. To get this behavior, add the newline character to `electricKeys` in the xml-escaped form &#xA;

- `ignoreWhitespace`: Ignore whitespace lines. This property is on (`true`) by default. Python language sets this to `false` because of the special treatment of whitespaces. Note this example:

      def fun1:
          a = 1
          b = 2

      def fun2:

  Pressing C+i (Indent Lines command) on the `fun2` line would usually indent this line and make it even with the `b = 2` line. But with switched off `ignoreWhitespace` setting the line will stay the way it was indented manually. `ignoreWhitespace=false` setting prevents any forward indentation after a whitespace line.

Here is the complete `<PROPS>` tag for Java mode:

    <PROPS>
        <PROPERTY NAME="commentStart" VALUE="/*" />
        <PROPERTY NAME="commentEnd" VALUE="*/" />
        <PROPERTY NAME="lineComment" VALUE="//" />
        <PROPERTY NAME="wordBreakChars" VALUE=",+-=&lt;&gt;/?^&amp;*" />

        <!-- Auto indent -->
        <PROPERTY NAME="indentOpenBrackets" VALUE="{" />
        <PROPERTY NAME="indentCloseBrackets" VALUE="}" />
        <PROPERTY NAME="unalignedOpenBrackets" VALUE="(" />
        <PROPERTY NAME="unalignedCloseBrackets" VALUE=")" />
        <PROPERTY NAME="indentNextLine"
        	VALUE="\s*(((if|while)\s*\(|else\s*|else\s+if\s*\(|for\s*\(.*\))[^{;]*)" />
        <PROPERTY NAME="unindentThisLine"
        	VALUE="^.*(default:\s*|case.*:.*)$" />
        <PROPERTY NAME="electricKeys" VALUE=":" />
        <!-- set this to 'true' if you want to use GNU coding style -->
        <PROPERTY NAME="doubleBracketIndent" VALUE="false" />
        <PROPERTY NAME="lineUpClosingBracket" VALUE="true" />
    </PROPS>

## The RULES Tag

`RULES` tags must be placed inside the `MODE` tag. Each `RULES` tag defines a ruleset. A ruleset consists of a number of parser rules, with each parser rule specifying how to highlight a specific syntax token. There must be at least one ruleset in each edit mode. There can also be more than one, with different rulesets being used to highlight different parts of a buffer (for example, in HTML mode, one rule set highlights HTML tags, and another highlights inline JavaScript). For information about using more than one ruleset, see .

The `RULES` tag supports the following attributes, all of which are optional:

- `SET` - the name of this ruleset. All rulesets other than the first must have a name.

- `IGNORE_CASE` - if set to `FALSE`, matches will be case sensitive. Otherwise, case will not matter. Default is `TRUE`.

- `ESCAPE` - specifies a character sequence for escaping literals. The first character following the escape sequence is not considered as input for syntax highlighting, thus being highlighted with default token for the rule set.

- `NO_WORD_SEP` - any non-alphanumeric character not in this list is treated as a word separator for the purposes of syntax highlighting.

- `DEFAULT` - the token type for text which doesn't match any specific rule. Default is `NULL`. See for a list of token types.

- `HIGHLIGHT_DIGITS`

- `DIGIT_RE` - see below for information about these two attributes.

Here is an example `RULES` tag:

    <RULES IGNORE_CASE="FALSE" HIGHLIGHT_DIGITS="TRUE">
        ... parser rules go here ...
    </RULES>

### Highlighting Numbers

If the `HIGHLIGHT_DIGITS` attribute is set to `TRUE`, jEdit will attempt to highlight numbers in this ruleset.

Any word consisting entirely of digits (0-9) will be highlighted with the `DIGIT` token type. A word that contains other letters in addition to digits will be highlighted with the `DIGIT` token type only if it matches the regular expression specified in the `DIGIT_RE` attribute. If this attribute is not specified, it will not be highlighted.

Here is an example `DIGIT_RE` regular expression that highlights Java-style numeric literals (normal numbers, hexadecimals prefixed with `0x`, numbers suffixed with various type indicators, and floating point literals containing an exponent). Note that newlines have been inserted here for readability.

    DIGIT_RE="(0[lL]?|[1-9]\d{0,9}(\d{0,9}[lL])?
    |0[xX]\p{XDigit}{1,8}(\p{XDigit}{0,8}[lL])?
    |0[0-7]{1,11}([0-7]{0,11}[lL])?|([0-9]+\.[0-9]*
    |\.[0-9]+)([eE][+-]?[0-9]+)?[fFdD]?|[0-9]+([eE][+-]?[0-9]+[fFdD]?
    |([eE][+-]?[0-9]+)?[fFdD]))"

Regular expression syntax is described in .

### Rule Ordering Requirements

You might encounter this very common pitfall when writing your own modes.

Since jEdit checks buffer text against parser rules in the order they appear in the ruleset, more specific rules must be placed before generalized ones, otherwise the generalized rules will catch everything.

This is best demonstrated with an example. The following is incorrect rule ordering:

    <SPAN TYPE="MARKUP">
        <BEGIN>[</BEGIN>
        <END>]</END>
    </SPAN>

    <SPAN TYPE="KEYWORD1">
        <BEGIN>[!</BEGIN>
        <END>]</END>
    </SPAN>

If you write the above in a rule set, any occurrence of [ (even things like [!DEFINE, etc) will be highlighted using the first rule, because it will be the first to match. This is most likely not the intended behavior.

The problem can be solved by placing the more specific rule before the general one:

    <SPAN TYPE="KEYWORD1">
        <BEGIN>[!</BEGIN>
        <END>]</END>
    </SPAN>

    <SPAN TYPE="MARKUP">
        <BEGIN>[</BEGIN>
        <END>]</END>
    </SPAN>

Now, if the buffer contains the text [!SPECIAL], the rules will be checked in order, and the first rule will be the first to match. However, if you write [FOO], it will be highlighted using the second rule, which is exactly what you would expect.

### Per-Ruleset Properties

The `PROPS` tag (described in ) can also be placed inside the `RULES` tag to define ruleset-specific properties. The following properties can be set on a per-ruleset basis:

- `commentEnd` - the comment end string.

- `commentStart` - the comment start string.

- `lineComment` - the line comment string.

This allows different parts of a file to have different comment strings (in the case of HTML, for example, in HTML text and inline JavaScript). For information about the commenting commands, see .

## The TERMINATE Tag

The `TERMINATE` rule, which must be placed inside a `RULES` tag, specifies that parsing should stop after the specified number of characters have been read from a line. The number of characters to terminate after should be specified with the `AT_CHAR` attribute. Here is an example:

    <TERMINATE AT_CHAR="1" />

This rule is used in Patch mode, for example, because only the first character of each line affects highlighting.

## The SPAN Tag

The `SPAN` rule, which must be placed inside a `RULES` tag, highlights text between a start and end string. The start and end strings are specified inside child elements of the `SPAN` tag. The following attributes are supported:

- `TYPE` - The token type to highlight the span with. See for a list of token types.

- `AT_LINE_START` - If set to `TRUE`, the span will only be highlighted if the start sequence occurs at the beginning of a line.

- `AT_WHITESPACE_END` - If set to `TRUE`, the span will only be highlighted if the start sequence is the first non-whitespace text in the line.

- `AT_WORD_START` - If set to `TRUE`, the span will only be highlighted if the start sequence occurs at the beginning of a word.

- `DELEGATE` - text inside the span will be highlighted with the specified ruleset. To delegate to a ruleset defined in the current mode, just specify its name. To delegate to a ruleset defined in another mode, specify a name of the form `mode::ruleset`. Note that the first (unnamed) ruleset in a mode is called MAIN.

- `MATCH_TYPE` - Controls how the start and end of the sequence will be highlighted. See for more information.

- `ESCAPE` - specifies a character sequence for escaping characters. The first character following the escape sequence is not considered as input for syntax highlighting, thus being highlighted with rule's token.

- `NO_LINE_BREAK` - If set to `TRUE`, the span will not cross line breaks.

- `NO_WORD_BREAK` - If set to `TRUE`, the span will not cross word breaks.

Note that the `AT_LINE_START`, `AT_WHITESPACE_END` and `AT_WORD_START` attributes can also be used on the `BEGIN` and `END` elements. Setting these attributes to the same value on both elements has the same effect as setting them on the `SPAN` element.

Here is a `SPAN` that highlights Java string literals, which cannot include line breaks:

    <SPAN TYPE="LITERAL1" NO_LINE_BREAK="TRUE">
      <BEGIN>"</BEGIN>
      <END>"</END>
    </SPAN>

Here is a `SPAN` that highlights Java documentation comments by delegating to the JAVADOC ruleset defined elsewhere in the current mode:

    <SPAN TYPE="COMMENT2" DELEGATE="JAVADOC">
      <BEGIN>/**</BEGIN>
      <END>*/</END>
    </SPAN>

Here is a `SPAN` that highlights HTML cascading stylesheets inside `<STYLE>` tags by delegating to the main ruleset in the CSS edit mode:

    <SPAN TYPE="MARKUP" DELEGATE="css::MAIN">
      <BEGIN>&lt;style&gt;</BEGIN>
      <END>&lt;/style&gt;</END>
    </SPAN>

## The SPAN_REGEXP Tag

The `SPAN_REGEXP` rule is similar to the `SPAN` rule except the start sequence and optionally the end sequence are taken to be regular expressions. In addition to the attributes supported by the `SPAN` tag, the following attributes are supported:

- `HASH_CHAR` - a literal string which must be at the start of a regular expression.

- `HASH_CHARS` - a list of possible literal characters, one of which must match at the start of the regular expression.

`HASH_CHAR` and `HASH_CHARS` attributes are both optional, but you may only specify one, not both. If both are specified, `HASH_CHARS` is ignored and an error is shown. Whenever possible, use a literal prefix to specify a `SPAN_REGEXP`. If the starting prefix is always the same, use `HASH_CHAR` and provide as much prefix as possible. Only in rare cases would you omit both attributes, such as the case where there is no other reliable way to get the highlighting you need, for example, with comments in the Cobol programming language.

In addition, the `END` subtag supports the attribute `REGEXP`, which if set to `TRUE`, tells the highlighter to interpret the `END` text as a regular expression as well.

The regular expression match cannot span more than one line. Any text matched by groups in the `BEGIN` regular expression is substituted in the `END` string. See below for an example of where this is useful.

Regular expression syntax is described in .

Here is a `SPAN_REGEXP` rule that highlights read-ins in shell scripts:

    <SPAN_REGEXP HASH_CHAR="&lt;" TYPE="LITERAL1" DELEGATE="LITERAL">
        <BEGIN><![CDATA[<<[\p{Space}'"]*([\p{Alnum}_]+)[\p{Space}'"]*]]></BEGIN>
        <END>$1</END>
    </SPAN_REGEXP>

Here is a `SPAN_REGEXP` rule that highlights constructs placed between `<#ftl` and `>`, as long as the `<#ftl` is followed by a word break:

    <SPAN_REGEXP TYPE="KEYWORD1" HASH_CHAR="&lt;" DELEGATE="EXPRESSION">
        <BEGIN>&lt;#ftl\b</BEGIN>
        <END>&gt;</END>
    </SPAN_REGEXP>

## The EOL_SPAN Tag

An `EOL_SPAN` is similar to a `SPAN` except that highlighting stops at the end of the line, and no end sequence needs to be specified. The text to match is specified between the opening and closing `EOL_SPAN` tags. The following attributes are supported:

- `TYPE` - The token type to highlight the span with. See for a list of token types.

- `AT_LINE_START` - If set to `TRUE`, the span will only be highlighted if the start sequence occurs at the beginning of a line.

- `AT_WHITESPACE_END` - If set to `TRUE`, the span will only be highlighted if the sequence is the first non-whitespace text in the line.

- `AT_WORD_START` - If set to `TRUE`, the span will only be highlighted if the start sequence occurs at the beginning of a word.

- `DELEGATE` - text inside the span will be highlighted with the specified ruleset. To delegate to a ruleset defined in the current mode, just specify its name. To delegate to a ruleset defined in another mode, specify a name of the form `mode::ruleset`. Note that the first (unnamed) ruleset in a mode is called MAIN.

- `MATCH_TYPE` - Controls how the start of the sequence will be highlighted. See for more information.

Here is an `EOL_SPAN` that highlights C++ comments:

    <EOL_SPAN TYPE="COMMENT1">//</EOL_SPAN>

## The EOL_SPAN_REGEXP Tag

The `EOL_SPAN_REGEXP` rule is similar to the `EOL_SPAN` rule except the match sequence is taken to be a regular expression. In addition to the attributes supported by the `EOL_SPAN` tag, the following attributes are supported:

- `HASH_CHAR` - a literal string which must be at the start of a regular expression.

- `HASH_CHARS` - a list of possible literal characters, one of which must match at the start of the regular expression.

`HASH_CHAR` and `HASH_CHARS` attributes are both optional, but you may only specify one, not both. If both are specified, `HASH_CHARS` is ignored and an error is shown. Whenever possible, use a literal prefix to specify a `EOL_SPAN_REGEXP`. If the starting prefix is always the same, use `HASH_CHAR` and provide as much prefix as possible. Only in rare cases would you omit both attributes, such as the case where there is no other reliable way to get the highlighting you need, for example, with comments in the Cobol programming language.

The regular expression match cannot span more than one line.

Regular expression syntax is described in .

Here is an `EOL_SPAN_REGEXP` that highlights MS-DOS batch file comments, which start with `REM`, followed by any whitespace character, and extend until the end of the line:

    <EOL_SPAN_REGEXP AT_WHITESPACE_END="TRUE" HASH_CHAR="REM" TYPE="COMMENT1">REM\s</EOL_SPAN_REGEXP>

## The MARK_PREVIOUS Tag

The `MARK_PREVIOUS` rule, which must be placed inside a `RULES` tag, highlights from the end of the previous syntax token to the matched text. The text to match is specified between opening and closing `MARK_PREVIOUS` tags. The following attributes are supported:

- `TYPE` - The token type to highlight the text with. See for a list of token types.

- `AT_LINE_START` - If set to `TRUE`, the sequence will only be highlighted if it occurs at the beginning of a line.

- `AT_WHITESPACE_END` - If set to `TRUE`, the sequence will only be highlighted if it is the first non-whitespace text in the line.

- `AT_WORD_START` - If set to `TRUE`, the sequence will only be highlighted if it occurs at the beginning of a word.

- `MATCH_TYPE` - Controls how the matched region will be highlighted. See for more information.

Here is a rule that highlights labels in Java mode (for example, XXX:):

    <MARK_PREVIOUS AT_WHITESPACE_END="TRUE"
       MATCH_TYPE="DEFAULT">:</MARK_PREVIOUS>

## The MARK_FOLLOWING Tag

The `MARK_FOLLOWING` rule, which must be placed inside a `RULES` tag, highlights from the start of the match to the next syntax token. The text to match is specified between opening and closing `MARK_FOLLOWING` tags. The following attributes are supported:

- `TYPE` - The token type to highlight the text with. See for a list of token types.

- `AT_LINE_START` - If set to `TRUE`, the sequence will only be highlighted if it occurs at the beginning of a line.

- `AT_WHITESPACE_END` - If set to `TRUE`, the sequence will only be highlighted if it is the first non-whitespace text in the line.

- `AT_WORD_START` - If set to `TRUE`, the sequence will only be highlighted if it occurs at the beginning of a word.

- `MATCH_TYPE` - Controls how the matched region will be highlighted. See for more information.

Here is a rule that highlights variables in Unix shell scripts ($CLASSPATH, $IFS, etc):

    <MARK_FOLLOWING TYPE="KEYWORD2">$</MARK_FOLLOWING>

## The SEQ Tag

The `SEQ` rule, which must be placed inside a `RULES` tag, highlights fixed sequences of text. The text to highlight is specified between opening and closing `SEQ` tags. The following attributes are supported:

- `TYPE` - the token type to highlight the sequence with. See for a list of token types.

- `AT_LINE_START` - If set to `TRUE`, the sequence will only be highlighted if it occurs at the beginning of a line.

- `AT_WHITESPACE_END` - If set to `TRUE`, the sequence will only be highlighted if it is the first non-whitespace text in the line.

- `AT_WORD_START` - If set to `TRUE`, the sequence will only be highlighted if it occurs at the beginning of a word.

- `DELEGATE` - if this attribute is specified, all text after the sequence will be highlighted using this ruleset. To delegate to a ruleset defined in the current mode, just specify its name. To delegate to a ruleset defined in another mode, specify a name of the form `mode::ruleset`. Note that the first (unnamed) ruleset in a mode is called MAIN.

The following rules highlight a few Java operators:

    <SEQ TYPE="OPERATOR">+</SEQ>
    <SEQ TYPE="OPERATOR">-</SEQ>
    <SEQ TYPE="OPERATOR">*</SEQ>
    <SEQ TYPE="OPERATOR">/</SEQ>

## The SEQ_REGEXP Tag

The `SEQ_REGEXP` rule is similar to the `SEQ` rule except the match sequence is taken to be a regular expression. In addition to the attributes supported by the `SEQ` tag, the following attributes are supported:

- `HASH_CHAR` - a literal string which must be at the start of a regular expression.

- `HASH_CHARS` - a list of possible literal characters, one of which must match at the start of the regular expression.

`HASH_CHAR` and `HASH_CHARS` attributes are both optional, but you may only specify one, not both. If both are specified, `HASH_CHARS` is ignored and an error is shown. Whenever possible, use a literal prefix to specify a `SEQ_REGEXP`. If the starting prefix is always the same, use `HASH_CHAR` and provide as much prefix as possible. Only in rare cases would you omit both attributes, such as the case where there is no other reliable way to get the highlighting you need, for example, with comments in the Cobol programming language.

The regular expression match cannot span more than one line.

Regular expression syntax is described in .

NOTE: c-style character escaping for literals (such as the tab char: \t) do not work as attribute values in XML. Use the XML character entity instead. For example: &#09; instead of \t.

Here is a `SEQ_REGEXP` rule from moin.xml that uses the `HASH_CHARS` attribute, to describe a keyword (wikiword) that can start with any uppercase letter and contain lower case letters and at least one uppercase letter in the middle.

     		<SEQ_REGEXP HASH_CHARS="ABCDEFGHIJKLMNOPQRSTUVWXYZ" AT_WORD_START="TRUE"
     		TYPE="KEYWORD2">[A-Z][a-z]+[A-Z][a-zA-Z]+</SEQ_REGEXP>

## The IMPORT Tag

The `IMPORT` tag, which must be placed inside a `RULES` tag, loads all rules defined in a given ruleset into the current ruleset; in other words, it has the same effect as copying and pasting the imported ruleset.

The only required attribute `DELEGATE` must be set to the name of a ruleset. To import a ruleset defined in the current mode, just specify its name. To import a ruleset defined in another mode, specify a name of the form `mode::ruleset`. Note that the first (unnamed) ruleset in a mode is called MAIN.

One quirk is that the definition of the imported ruleset is not copied to the location of the `IMPORT` tag, but rather to the end of the containing ruleset. This has implications with rule-ordering; see .

Here is an example from the PHP mode, which extends the inline JavaScript highlighting to support embedded PHP:

       <RULES SET="JAVASCRIPT+PHP">

       <SPAN TYPE="MARKUP" DELEGATE="php::PHP">
           <BEGIN>&lt;?php</BEGIN>
           <END>?&gt;</END>
       </SPAN>

       <SPAN TYPE="MARKUP" DELEGATE="php::PHP">
           <BEGIN>&lt;?</BEGIN>
           <END>?&gt;</END>
       </SPAN>

       <SPAN TYPE="MARKUP" DELEGATE="php::PHP">
           <BEGIN>&lt;%=</BEGIN>
           <END>%&gt;</END>
       </SPAN>

       <IMPORT DELEGATE="javascript::MAIN"/>
    </RULES>

## The KEYWORDS Tag

The `KEYWORDS` tag, which must be placed inside a `RULES` tag and can only appear once, specifies a list of keywords to highlight. Keywords are similar to `SEQ`s, except that `SEQ`s match anywhere in the text, whereas keywords only match whole words. Words are considered to be runs of text separated by non-alphanumeric characters.

The `KEYWORDS` tag does not define any attributes.

Each child element of the `KEYWORDS` tag is an element whose name is a token type, and whose content is the keyword to highlight. For example, the following rule highlights the most common Java keywords:

    <KEYWORDS>
      <KEYWORD1>if</KEYWORD1>
      <KEYWORD1>else</KEYWORD1>
      <KEYWORD3>int</KEYWORD3>
      <KEYWORD3>void</KEYWORD3>
    </KEYWORDS>

## Token Types

Parser rules can highlight tokens using any of the following token types:

- `NULL` - no special highlighting is performed on tokens of type `NULL`

- `COMMENT1`

- `COMMENT2`

- `COMMENT3`

- `COMMENT4`

- `FUNCTION`

- `DIGIT`

- `INVALID`

- `KEYWORD1`

- `KEYWORD2`

- `KEYWORD3`

- `KEYWORD4`

- `LABEL`

- `LITERAL1`

- `LITERAL2`

- `LITERAL3`

- `LITERAL4`

- `MARKUP`

- `OPERATOR`

## The MATCH_TYPE Attribute

The `MATCH_TYPE` attribute is used by some of the rules to control how the region matched by the rule will be highlighted.

For example, when using a `MARK_PREVIOUS` rule to highlight a function call of the form `fcall()`, the following rule could be used:

       <MARK_PREVIOUS TYPE="FUNCTION" MATCH_TYPE="OPERATOR">(</MARK_PREVIOUS>

This would cause `fcall` to be highlighted as `FUNCTION`, and `(` to be highlighted as `OPERATOR`. In this case, to maintain bracket matching working, a `SEQ` rule would have to be added to match `)` and mark it as `OPERATOR`.

The `MATCH_TYPE` attribute value can be any of the valid token types, or the following special values:

- `RULE`: this is the default value. It tells the syntax system to use the same token type as the TYPE attribute of the rule. This is equivalent to `EXCLUDE_MATCH="FALSE"` in 4.2 and earlier mode files.

- `CONTEXT`: using this value tells the syntax system to mark the matched region using the default token type for the current rule set. In 4.2 and earlier mode files, this was specified by `EXCLUDE_MATCH="TRUE"`.