ccmode: Font Locking Preliminaries
5.1 Font Locking Preliminaries
==============================
The font locking for most of the CC Mode languages were provided
directly by the Font Lock package prior to version 5.30 of CC Mode. In
the transition to CC Mode the patterns have been reworked completely and
are applied uniformly across all the languages except AWK mode, just
like the indentation rules (although each language still has some
peculiarities of its own, of course). Since the languages previously
had completely separate font locking patterns, this means that it’s a
bit different in most languages now.
The main goal for the font locking in CC Mode is accuracy, to provide
a dependable aid in recognizing the various constructs. Some, like
strings and comments, are easy to recognize while others, like
declarations and types, can be very tricky. CC Mode can go to great
lengths to recognize declarations and casts correctly, especially when
the types aren’t recognized by standard patterns. This is a fairly
demanding analysis which can be slow on older hardware, and it can
therefore be disabled by choosing a lower decoration level with the
variable ‘font-lock-maximum-decoration’ (
(emacs)Font Lock).
The decoration levels are used as follows:
1. Minimal font locking: Fontify only comments, strings and
preprocessor directives (in the languages that use cpp).
2. Fast font locking: In addition to level 1, fontify keywords, simple
types and declarations that are easy to recognize. The variables
‘*-font-lock-extra-types’ (where ‘*’ is the name of the language)
are used to recognize types (see below). Documentation comments
like Javadoc are fontified according to ‘c-doc-comment-style’
(Doc Comments).
Use this if you think the font locking is too slow. It’s the
closest corresponding level to level 3 in the old font lock
patterns.
3. Accurate font locking: Like level 2 but uses a different approach
that can recognize types and declarations much more accurately.
The ‘*-font-lock-extra-types’ variables are still used, but user
defined types are recognized correctly anyway in most cases.
Therefore those variables should be fairly restrictive and not
contain patterns that are uncertain.
This level is designed for fairly modern hardware and a font lock
support mode like Lazy Lock or Just-in-time Lock mode that only
fontifies the parts that are actually shown. Fontifying the whole
buffer at once can easily get bothersomely slow even on
contemporary hardware. (emacs)Font Lock.
Since user defined types are hard to recognize you can provide
additional regexps to match those you use:
-- User Option: c-font-lock-extra-types
-- User Option: c++-font-lock-extra-types
-- User Option: objc-font-lock-extra-types
-- User Option: java-font-lock-extra-types
-- User Option: idl-font-lock-extra-types
-- User Option: pike-font-lock-extra-types
For each language there’s a variable ‘*-font-lock-extra-types’,
where ‘*’ stands for the language in question. It contains a list
of regexps that matches identifiers that should be recognized as
types, e.g., ‘\\sw+_t’ to recognize all identifiers ending with
‘_t’ as is customary in C code. Each regexp should not match more
than a single identifier.
The default values contain regexps for many types in standard
runtime libraries that are otherwise difficult to recognize, and
patterns for standard type naming conventions like the ‘_t’ suffix
in C and C++. Java, Objective-C and Pike have as a convention to
start class names with capitals, so there are patterns for that in
those languages.
Despite the names of these variables, they are not only used for
fontification but in other places as well where CC Mode needs to
recognize types.
Info Catalog
ccmode: Font Locking
ccmode: Font Locking
ccmode: Faces