+@node Properties in Mode
+@subsection Properties in the Mode Line
+
+ Starting in Emacs 21, certain text properties are meaningful in the
+mode line. The @code{face} property affects the appearance of text; the
+@code{help-echo} property associate help strings with the text, and
+@code{local-map} can make the text mouse-sensitive.
+
+ There are three ways to specify text properties for text in the mode
+line:
+
+@enumerate
+@item
+Put a string with the @code{local-map} property directly into the
+mode-line data structure.
+
+@item
+Put a @code{local-map} property on a mode-line %-construct
+such as @samp{%12b}; then the expansion of the %-construct
+will have that same text property.
+
+@item
+Use a list containing @code{:eval @var{form}} in the mode-line data
+structure, and make @var{form} evaluate to a string that has a
+@code{local-map} property.
+@end enumerate
+
+ You use the @code{local-map} property to specify a keymap. Like any
+keymap, it can bind character keys and function keys; but that has no
+effect, since it is impossible to move point into the mode line. This
+keymap can only take real effect for mouse clicks.
+
+@node Header Lines
+@subsection Window Header Lines
+@cindex header line (of a window)
+@cindex window header line
+
+ Starting in Emacs 21, a window can have a @dfn{header line} at the
+top, just as it can have a mode line at the bottom. The header line
+feature works just like the mode line feature, except that it's
+controlled by different variables.
+
+@tindex header-line-format
+@defvar header-line-format
+This variable, local in every buffer, specifies how to display the
+header line, for windows displaying the buffer. The format of the value
+is the same as for @code{mode-line-format} (@pxref{Mode Line Data}).
+@end defvar
+
+@tindex default-header-line-format
+@defvar default-header-line-format
+This variable holds the default @code{header-line-format} for buffers
+that do not override it. This is the same as @code{(default-value
+'header-line-format)}.
+
+It is normally @code{nil}, so that ordinary buffers have no header line.
+@end defvar
+
+@node Imenu
+@section Imenu
+
+@cindex Imenu
+ @dfn{Imenu} is a feature that lets users select a definition or
+section in the buffer, from a menu which lists all of them, to go
+directly to that location in the buffer. Imenu works by constructing a
+buffer index which lists the names and buffer positions of the
+definitions, or other named portions of the buffer; then the user can
+choose one of them and move point to it. This section explains how to
+customize how Imenu finds the definitions or buffer portions for a
+particular major mode.
+
+ The usual and simplest way is to set the variable
+@code{imenu-generic-expression}:
+
+@defvar imenu-generic-expression
+This variable, if non-@code{nil}, specifies regular expressions for
+finding definitions for Imenu. In the simplest case, elements should
+look like this:
+
+@example
+(@var{menu-title} @var{regexp} @var{subexp})
+@end example
+
+Here, if @var{menu-title} is non-@code{nil}, it says that the matches
+for this element should go in a submenu of the buffer index;
+@var{menu-title} itself specifies the name for the submenu. If
+@var{menu-title} is @code{nil}, the matches for this element go directly
+in the top level of the buffer index.
+
+The second item in the list, @var{regexp}, is a regular expression
+(@pxref{Regular Expressions}); anything in the buffer that it matches is
+considered a definition, something to mention in the buffer index. The
+third item, @var{subexp}, indicates which subexpression in @var{regexp}
+matches the definition's name.
+
+An element can also look like this:
+
+@example
+(@var{menu-title} @var{regexp} @var{index} @var{function} @var{arguments}@dots{})
+@end example
+
+Each match for this element creates a special index item which, if
+selected by the user, calls @var{function} with arguments consisting of
+the item name, the buffer position, and @var{arguments}.
+
+For Emacs Lisp mode, @var{pattern} could look like this:
+
+@c should probably use imenu-syntax-alist and \\sw rather than [-A-Za-z0-9+]
+@example
+@group
+((nil "^\\s-*(def\\(un\\|subst\\|macro\\|advice\\)\
+\\s-+\\([-A-Za-z0-9+]+\\)" 2)
+@end group
+@group
+ ("*Vars*" "^\\s-*(def\\(var\\|const\\)\
+\\s-+\\([-A-Za-z0-9+]+\\)" 2)
+@end group
+@group
+ ("*Types*"
+ "^\\s-*\
+(def\\(type\\|struct\\|class\\|ine-condition\\)\
+\\s-+\\([-A-Za-z0-9+]+\\)" 2))
+@end group
+@end example
+
+Setting this variable makes it buffer-local in the current buffer.
+@end defvar
+
+@defvar imenu-case-fold-search
+This variable controls whether matching against
+@var{imenu-generic-expression} is case-sensitive: @code{t}, the default,
+means matching should ignore case.
+
+Setting this variable makes it buffer-local in the current buffer.
+@end defvar
+
+@defvar imenu-syntax-alist
+This variable is an alist of syntax table modifiers to use while
+processing @code{imenu-generic-expression}, to override the syntax table
+of the current buffer. Each element should have this form:
+
+@example
+(@var{characters} . @var{syntax-description})
+@end example
+
+The @sc{car}, @var{characters}, can be either a character or a string.
+The element says to give that character or characters the syntax
+specified by @var{syntax-description}, which is passed to
+@code{modify-syntax-entry} (@pxref{Syntax Table Functions}).
+
+This feature is typically used to give word syntax to characters which
+normally have symbol syntax, and thus to simplify
+@code{imenu-generic-expression} and speed up matching.
+For example, Fortran mode uses it this way:
+
+@example
+ (setq imenu-syntax-alist '(("_$" . "w")))
+@end example
+
+The @code{imenu-generic-expression} patterns can then use @samp{\\sw+}
+instead of @samp{\\(\\sw\\|\\s_\\)+}. Note that this technique may be
+inconvenient when the mode needs to limit the initial character
+of a name to a smaller set of characters than are allowed in the rest
+of a name.
+
+Setting this variable makes it buffer-local in the current buffer.
+@end defvar
+
+ Another way to customize Imenu for a major mode is to set the
+variables @code{imenu-prev-index-position-function} and
+@code{imenu-extract-index-name-function}:
+
+@defvar imenu-prev-index-position-function
+If this variable is non-@code{nil}, its value should be a function that
+finds the next ``definition'' to put in the buffer index, scanning
+backward in the buffer from point. It should return @code{nil} if it
+doesn't find another ``definition'' before point. Otherwise it shuould
+leave point at the place it finds a ``definition,'' and return any
+non-@code{nil} value.
+
+Setting this variable makes it buffer-local in the current buffer.
+@end defvar
+
+@defvar imenu-extract-index-name-function
+If this variable is non-@code{nil}, its value should be a function to
+return the name for a definition, assuming point is in that definition
+as the @code{imenu-prev-index-position-function} function would leave
+it.
+
+Setting this variable makes it buffer-local in the current buffer.
+@end defvar
+
+ The last way to customize Imenu for a major mode is to set the
+variable @code{imenu-create-index-function}:
+
+@defvar imenu-create-index-function
+This variable specifies the function to use for creating a buffer index.
+The function should take no arguments, and return an index for the
+current buffer. It is called within @code{save-excursion}, so where it
+leaves point makes no difference.
+
+The default value is a function that uses
+@code{imenu-generic-expression} to produce the index alist. If you
+specify a different function, then @code{imenu-generic-expression} is
+not used.
+
+Setting this variable makes it buffer-local in the current buffer.
+@end defvar
+
+@defvar imenu-index-alist
+This variable holds the index alist for the current buffer.
+Setting it makes it buffer-local in the current buffer.
+
+Simple elements in the alist look like @code{(@var{index-name}
+. @var{index-position})}. Selecting a simple element has the effect of
+moving to position @var{index-position} in the buffer.
+
+Special elements look like @code{(@var{index-name} @var{position}
+@var{function} @var{arguments}@dots{})}. Selecting a special element
+performs
+
+@example
+(funcall @var{function} @var{index-name} @var{position} @var{arguments}@dots{})
+@end example
+
+A nested sub-alist element looks like @code{(@var{index-name}
+@var{sub-alist})}.
+@end defvar
+
+@node Font Lock Mode
+@section Font Lock Mode
+@cindex Font Lock Mode
+
+ @dfn{Font Lock mode} is a feature that automatically attaches
+@code{face} properties to certain parts of the buffer based on their
+syntactic role. How it parses the buffer depends on the major mode;
+most major modes define syntactic criteria for which faces to use in
+which contexts. This section explains how to customize Font Lock for a
+particular major mode.
+
+ Font Lock mode finds text to highlight in two ways: through syntactic
+parsing based on the syntax table, and through searching (usually for
+regular expressions). Syntactic fontification happens first; it finds
+comments and string constants, and highlights them using
+@code{font-lock-comment-face} and @code{font-lock-string-face}
+(@pxref{Faces for Font Lock}). Search-based fontification follows.
+
+@menu
+* Font Lock Basics::
+* Search-based Fontification::
+* Other Font Lock Variables::
+* Levels of Font Lock::
+* Faces for Font Lock::
+* Syntactic Font Lock::
+@end menu
+
+@node Font Lock Basics
+@subsection Font Lock Basics
+
+ There are several variables that control how Font Lock mode highlights
+text. But major modes should not set any of these variables directly.
+Instead, they should set @code{font-lock-defaults} as a buffer-local
+variable. The value assigned to this variable is used, if and when Font
+Lock mode is enabled, to set all the other variables.
+
+@defvar font-lock-defaults
+This variable is set by major modes, as a buffer-local variable, to
+specify how to fontify text in that mode. The value should look like
+this:
+
+@example
+(@var{keywords} @var{keywords-only} @var{case-fold}
+ @var{syntax-alist} @var{syntax-begin} @var{other-vars}@dots{})
+@end example
+
+The first element, @var{keywords}, indirectly specifies the value of
+@code{font-lock-keywords}. It can be a symbol, a variable whose value
+is the list to use for @code{font-lock-keywords}. It can also be a list of
+several such symbols, one for each possible level of fontification. The
+first symbol specifies how to do level 1 fontification, the second
+symbol how to do level 2, and so on.
+
+The second element, @var{keywords-only}, specifies the value of the
+variable @code{font-lock-keywords-only}. If this is non-@code{nil},
+syntactic fontification (of strings and comments) is not performed.
+
+The third element, @var{case-fold}, specifies the value of
+@code{font-lock-case-fold-search}. If it is non-@code{nil}, Font Lock
+mode ignores case when searching as directed by
+@code{font-lock-keywords}.
+
+If the fourth element, @var{syntax-alist}, is non-@code{nil}, it should be
+a list of cons cells of the form @code{(@var{char-or-string}
+. @var{string})}. These are used to set up a syntax table for
+fontification (@pxref{Syntax Table Functions}). The resulting syntax
+table is stored in @code{font-lock-syntax-table}.
+
+The fifth element, @var{syntax-begin}, specifies the value of
+@code{font-lock-beginning-of-syntax-function} (see below).
+
+All the remaining elements (if any) are collectively called
+@var{other-vars}. Each of these elements should have the form
+@code{(@var{variable} . @var{value})}---which means, make @var{variable}
+buffer-local and then set it to @var{value}. You can use these
+@var{other-vars} to set other variables that affect fontification,
+aside from those you can control with the first five elements.
+@end defvar
+
+@node Search-based Fontification
+@subsection Search-based Fontification
+
+ The most important variable for customizing Font Lock mode is
+@code{font-lock-keywords}. It specifies the search criteria for
+search-based fontification.
+
+@defvar font-lock-keywords
+This variable's value is a list of the keywords to highlight. Be
+careful when composing regular expressions for this list; a poorly
+written pattern can dramatically slow things down!
+@end defvar
+
+ Each element of @code{font-lock-keywords} specifies how to find
+certain cases of text, and how to highlight those cases. Font Lock mode
+processes the elements of @code{font-lock-keywords} one by one, and for
+each element, it finds and handles all matches. Ordinarily, once
+part of the text has been fontified already, this cannot be overridden
+by a subsequent match in the same text; but you can specify different
+behavior using the @var{override} element of a @var{highlighter}.
+
+ Each element of @code{font-lock-keywords} should have one of these
+forms:
+
+@table @code
+@item @var{regexp}
+Highlight all matches for @var{regexp} using
+@code{font-lock-keyword-face}. For example,
+
+@example
+;; @r{Highlight discrete occurrences of @samp{foo}}
+;; @r{using @code{font-lock-keyword-face}.}
+"\\<foo\\>"
+@end example
+
+The function @code{regexp-opt} (@pxref{Syntax of Regexps}) is useful for
+calculating optimal regular expressions to match a number of different
+keywords.
+
+@item @var{function}
+Find text by calling @var{function}, and highlight the matches
+it finds using @code{font-lock-keyword-face}.
+
+When @var{function} is called, it receives one argument, the limit of
+the search. It should return non-@code{nil} if it succeeds, and set the
+match data to describe the match that was found.
+
+@item (@var{matcher} . @var{match})
+In this kind of element, @var{matcher} is either a regular
+expression or a function, as described above. The @sc{cdr},
+@var{match}, specifies which subexpression of @var{matcher} should be
+highlighted (instead of the entire text that @var{matcher} matched).
+
+@example
+;; @r{Highlight the @samp{bar} in each occurrence of @samp{fubar},}
+;; @r{using @code{font-lock-keyword-face}.}
+("fu\\(bar\\)" . 1)
+@end example
+
+If you use @code{regexp-opt} to produce the regular expression
+@var{matcher}, then you can use @code{regexp-opt-depth} (@pxref{Syntax
+of Regexps}) to calculate the value for @var{match}.
+
+@item (@var{matcher} . @var{facename})
+In this kind of element, @var{facename} is an expression whose value
+specifies the face name to use for highlighting.
+
+@example
+;; @r{Highlight occurrences of @samp{fubar},}
+;; @r{using the face which is the value of @code{fubar-face}.}
+("fubar" . fubar-face)
+@end example
+
+@item (@var{matcher} . @var{highlighter})
+In this kind of element, @var{highlighter} is a list
+which specifies how to highlight matches found by @var{matcher}.
+It has the form
+
+@example
+(@var{subexp} @var{facename} @var{override} @var{laxmatch})
+@end example
+
+The @sc{car}, @var{subexp}, is an integer specifying which subexpression
+of the match to fontify (0 means the entire matching text). The second
+subelement, @var{facename}, specifies the face, as described above.
+
+The last two values in @var{highlighter}, @var{override} and
+@var{laxmatch}, are flags. If @var{override} is @code{t}, this element
+can override existing fontification made by previous elements of
+@code{font-lock-keywords}. If it is @code{keep}, then each character is
+fontified if it has not been fontified already by some other element.
+If it is @code{prepend}, the face @var{facename} is added to the
+beginning of the @code{face} property. If it is @code{append}, the face
+@var{facename} is added to the end of the @code{face} property.
+
+If @var{laxmatch} is non-@code{nil}, it means there should be no error
+if there is no subexpression numbered @var{subexp} in @var{matcher}.
+Obviously, fontification of the subexpression numbered @var{subexp} will
+not occur. However, fontification of other subexpressions (and other
+regexps) will continue. If @var{laxmatch} is @code{nil}, and the
+specified subexpression is missing, then an error is signalled which
+terminates search-based fontification.
+
+Here are some examples of elements of this kind, and what they do:
+
+@smallexample
+;; @r{Highlight occurrences of either @samp{foo} or @samp{bar},}
+;; @r{using @code{foo-bar-face}, even if they have already been highlighted.}
+;; @r{@code{foo-bar-face} should be a variable whose value is a face.}
+("foo\\|bar" 0 foo-bar-face t)
+
+;; @r{Highlight the first subexpression within each occurrence}
+;; @r{that the function @code{fubar-match} finds,}
+;; @r{using the face which is the value of @code{fubar-face}.}
+(fubar-match 1 fubar-face)
+@end smallexample
+
+@item (@var{matcher} @var{highlighters}@dots{})
+This sort of element specifies several @var{highlighter} lists for a
+single @var{matcher}. In order for this to be useful, each
+@var{highlighter} should have a different value of @var{subexp}; that is,
+each one should apply to a different subexpression of @var{matcher}.
+
+@ignore
+@item (@var{matcher} . @var{anchored})
+In this kind of element, @var{anchored} acts much like a
+@var{highlighter}, but it is more complex and can specify multiple
+successive searches.
+
+For highlighting single items, typically only @var{highlighter} is
+required. However, if an item or (typically) items are to be
+highlighted following the instance of another item (the anchor) then
+@var{anchored} may be required.
+
+It has this format:
+
+@example
+(@var{submatcher} @var{pre-match-form} @var{post-match-form} @var{highlighters}@dots{})
+@end example
+
+@c I can't parse this text -- rms
+where @var{submatcher} is much like @var{matcher}, with one
+exception---see below. @var{pre-match-form} and @var{post-match-form}
+are evaluated before the first, and after the last, instance
+@var{anchored}'s @var{submatcher} is used. Therefore they can be used
+to initialize before, and cleanup after, @var{submatcher} is used.
+Typically, @var{pre-match-form} is used to move to some position
+relative to the original @var{submatcher}, before starting with
+@var{anchored}'s @var{submatcher}. @var{post-match-form} might be used
+to move, before resuming with @var{anchored}'s parent's @var{matcher}.
+
+For example, an element of the form highlights (if not already highlighted):
+
+@example
+("\\<anchor\\>" (0 anchor-face) ("\\<item\\>" nil nil (0 item-face)))
+@end example
+
+Discrete occurrences of @samp{anchor} in the value of
+@code{anchor-face}, and subsequent discrete occurrences of @samp{item}
+(on the same line) in the value of @code{item-face}. (Here
+@var{pre-match-form} and @var{post-match-form} are @code{nil}.
+Therefore @samp{item} is initially searched for starting from the end of
+the match of @samp{anchor}, and searching for subsequent instance of
+@samp{anchor} resumes from where searching for @samp{item} concluded.)
+
+The above-mentioned exception is as follows. The limit of the
+@var{submatcher} search defaults to the end of the line after
+@var{pre-match-form} is evaluated. However, if @var{pre-match-form}
+returns a position greater than the position after @var{pre-match-form}
+is evaluated, that position is used as the limit of the search. It is
+generally a bad idea to return a position greater than the end of the
+line; in other words, the @var{submatcher} search should not span lines.
+
+@item (@var{matcher} @var{highlighters-or-anchoreds} ...)
+@end ignore
+
+@item (eval . @var{form})
+Here @var{form} is an expression to be evaluated the first time
+this value of @code{font-lock-keywords} is used in a buffer.
+Its value should have one of the forms described in this table.
+@end table
+
+@strong{Warning:} Do not design an element of @code{font-lock-keywords}
+to match text which spans lines; this does not work reliably. While
+@code{font-lock-fontify-buffer} handles multi-line patterns correctly,
+updating when you edit the buffer does not, since it considers text one
+line at a time.
+
+@node Other Font Lock Variables
+@subsection Other Font Lock Variables
+
+ This section describes additional variables that a major mode
+can set by means of @code{font-lock-defaults}.
+
+@defvar font-lock-keywords-only
+Non-@code{nil} means Font Lock should not fontify comments or strings
+syntactically; it should only fontify based on
+@code{font-lock-keywords}.
+@end defvar
+
+@ignore
+Other variables include those for buffer-specialized fontification functions,
+`font-lock-fontify-buffer-function', `font-lock-unfontify-buffer-function',
+`font-lock-fontify-region-function', `font-lock-unfontify-region-function',
+`font-lock-inhibit-thing-lock' and `font-lock-maximum-size'.
+@end ignore
+
+@defvar font-lock-keywords-case-fold-search
+Non-@code{nil} means that regular expression matching for the sake of
+@code{font-lock-keywords} should be case-insensitive.
+@end defvar
+
+@defvar font-lock-syntax-table
+This variable specifies the syntax table to use for fontification of
+comments and strings.
+@end defvar
+
+@defvar font-lock-beginning-of-syntax-function
+If this variable is non-@code{nil}, it should be a function to move
+point back to a position that is syntactically at ``top level'' and
+outside of strings or comments. Font Lock uses this when necessary
+to get the right results for syntactic fontification.
+
+This function is called with no arguments. It should leave point at the
+beginning of any enclosing syntactic block. Typical values are
+@code{beginning-of-line} (i.e., the start of the line is known to be
+outside a syntactic block), or @code{beginning-of-defun} for programming
+modes or @code{backward-paragraph} for textual modes (i.e., the
+mode-dependent function is known to move outside a syntactic block).
+
+If the value is @code{nil}, the beginning of the buffer is used as a
+position outside of a syntactic block. This cannot be wrong, but it can
+be slow.
+@end defvar
+
+@defvar font-lock-mark-block-function
+If this variable is non-@code{nil}, it should be a function that is
+called with no arguments, to choose an enclosing range of text for
+refontification for the command @kbd{M-g M-g}
+(@code{font-lock-fontify-block}).
+
+The function should report its choice by placing the region around it.
+A good choice is a range of text large enough to give proper results,
+but not too large so that refontification becomes slow. Typical values
+are @code{mark-defun} for programming modes or @code{mark-paragraph} for
+textual modes.
+@end defvar
+
+@node Levels of Font Lock
+@subsection Levels of Font Lock
+
+ Many major modes offer three different levels of fontification. You
+can define multiple levels by using a list of symbols for @var{keywords}
+in @code{font-lock-defaults}. Each symbol specifies one level of
+fontification; it is up to the user to choose one of these levels. The
+chosen level's symbol value is used to initialize
+@code{font-lock-keywords}.
+
+ Here are the conventions for how to define the levels of
+fontification:
+
+@itemize @bullet
+@item
+Level 1: highlight function declarations, file directives (such as include or
+import directives), strings and comments. The idea is speed, so only
+the most important and top-level components are fontified.
+
+@item
+Level 2: in addition to level 1, highlight all language keywords,
+including type names that act like keywords, as well as named constant
+values. The idea is that all keywords (either syntactic or semantic)
+should be fontified appropriately.
+
+@item
+Level 3: in addition to level 2, highlight the symbols being defined in
+function and variable declarations, and all builtin function names,
+wherever they appear.
+@end itemize
+
+@node Faces for Font Lock
+@subsection Faces for Font Lock
+
+ You can make Font Lock mode use any face, but several faces are
+defined specifically for Font Lock mode. Each of these symbols is both
+a face name, and a variable whose default value is the symbol itself.
+Thus, the default value of @code{font-lock-comment-face} is
+@code{font-lock-comment-face}. This means you can write
+@code{font-lock-comment-face} in a context such as
+@code{font-lock-keywords} where a face-name-valued expression is used.
+
+@table @code
+@item font-lock-comment-face
+@vindex font-lock-comment-face
+Used (typically) for comments.
+
+@item font-lock-string-face
+@vindex font-lock-string-face
+Used (typically) for string constants.
+
+@item font-lock-keyword-face
+@vindex font-lock-keyword-face
+Used (typically) for keywords---names that have special syntactic
+significance, like @code{for} and @code{if} in C.
+
+@item font-lock-builtin-face
+@vindex font-lock-builtin-face
+Used (typically) for built-in function names.
+
+@item font-lock-function-name-face
+@vindex font-lock-function-name-face
+Used (typically) for the name of a function being defined or declared,
+in a function definition or declaration.
+
+@item font-lock-variable-name-face
+@vindex font-lock-variable-name-face
+Used (typically) for the name of a variable being defined or declared,
+in a variable definition or declaration.
+
+@item font-lock-type-face
+@vindex font-lock-type-face
+Used (typically) for names of user-defined data types,
+where they are defined and where they are used.
+
+@item font-lock-constant-face
+@vindex font-lock-constant-face
+Used (typically) for constant names.
+
+@item font-lock-warning-face
+@vindex font-lock-warning-face
+Used (typically) for constructs that are peculiar, or that greatly
+change the meaning of other text. For example, this is used for
+@samp{;;;###autoload} cookies in Emacs Lisp, and for @code{#error}
+directives in C.
+@end table
+
+@node Syntactic Font Lock
+@subsection Syntactic Font Lock
+
+ Font Lock mode can be used to update @code{syntax-table} properties
+automatically. This is useful in languages for which a single syntax
+table by itself is not sufficient.
+
+@defvar font-lock-syntactic-keywords
+This variable enables and controls syntactic Font Lock. Its value
+should be a list of elements of this form:
+
+@example
+(@var{matcher} @var{subexp} @var{syntax} @var{override} @var{laxmatch})
+@end example
+
+The parts of this element have the same meanings as in the corresponding
+sort of element of @code{font-lock-keywords},
+
+@example
+(@var{matcher} @var{subexp} @var{facename} @var{override} @var{laxmatch})
+@end example
+
+However, instead of specifying the value @var{facename} to use for the
+@code{face} property, it specifies the value @var{syntax} to use for the
+@code{syntax-table} property. Here, @var{syntax} can be a variable
+whose value is a syntax table, a syntax entry of the form
+@code{(@var{syntax-code} . @var{matching-char})}, or an expression whose
+value is one of those two types.
+@end defvar
+