+@kbd{RET}, you should consider switching to this function.
+
+@item @kbd{M-x c-context-open-line}
+@findex c-context-open-line
+@findex context-open-line (c-)
+This is to @kbd{C-o} (@kbd{M-x open-line}) as
+@code{c-context-line-break} is to @kbd{RET}. I.e., it works just like
+@code{c-context-line-break} but leaves the point before the inserted
+line break.
+@end table
+
+
+@comment !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+@node Macro Handling, Font Locking, Text Filling and Line Breaking, Top
+@comment node-name, next, previous, up
+@chapter Macro Handling
+@cindex macros
+@cindex preprocessor directives
+@comment !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+
+Preprocessor directives are handled as syntactic whitespace from other
+code, i.e., they can be interspersed anywhere without affecting the
+syntactic analysis, just like comments.
+
+The code inside macro definitions is still analyzed syntactically so
+that you get relative indentation there just as you'd get if the same
+code was outside a macro. However, since there is no hint about the
+syntactic context, i.e., whether the macro expands to an expression, to some
+statements, or perhaps to whole functions, the syntactic recognition can be
+wrong. @ccmode{} manages to figure it out correctly most of the time,
+though. @xref{Syntactic Symbols}, for details about the indentation.
+
+@defopt c-syntactic-indentation-in-macros
+@vindex syntactic-indentation-in-macros (c-)
+Enable syntactic analysis inside macros, which is the default. If this
+is @code{nil}, all lines inside macro definitions are analyzed as
+@code{cpp-macro-cont}.
+@end defopt
+
+@ccmode{} provides some tools to help keep the line continuation
+backslashes in macros neat and tidy:
+
+@table @asis
+@item @kbd{C-c C-\} (@code{c-backslash-region})
+@kindex C-c C-\
+@findex c-backslash-region
+@findex backslash-region (c-)
+This function inserts and aligns or deletes the end-of-line backslashes
+in the current region.
+
+With no prefix argument, it inserts any missing backslashes and aligns
+them according to the @code{c-backslash-column} and
+@code{c-backslash-max-column} variables. With a prefix argument, it
+deletes any backslashes.
+
+The function does not modify blank lines at the start of the region. If
+the region ends at the start of a line, it always deletes the backslash
+(if any) at the end of the previous line.
+@end table
+
+@defopt c-backslash-column
+@vindex backslash-column (c-)
+@defoptx c-backslash-max-column
+@vindex backslash-max-column (c-)
+These variables control the alignment columns for line continuation
+backslashes in multiline macros. They are used by the functions that
+automatically insert or align such backslashes,
+e.g., @code{c-backslash-region} and @code{c-context-line-break}.
+
+@code{c-backslash-column} specifies the minimum column for the
+backslashes. If any line in the macro exceeds it then the next tab
+stop from that line is used as the alignment column for all the
+backslashes, so that they remain in a single column. However, if some
+lines exceed @code{c-backslash-max-column} then the backslashes in the
+rest of the macro will be kept at that column, so that the
+lines which are too long ``stick out'' instead.
+@end defopt
+
+@defopt c-auto-align-backslashes
+@vindex auto-align-backslashes (c-)
+Align automatically inserted line continuation backslashes if
+non-@code{nil}. When line continuation backslashes are inserted
+automatically for line breaks in multiline macros, e.g., by
+@code{c-context-line-break}, they are aligned with the other backslashes
+in the same macro if this flag is set. Otherwise the inserted
+backslashes are preceded by a single space.
+@end defopt
+
+The recommended line breaking function, @code{c-context-line-break}
+(@pxref{Text Filling and Line Breaking}), is especially nice if you edit
+multiline macros frequently. When used inside a macro, it automatically
+inserts and adjusts the mandatory backslash at the end of the line to
+keep the macro together, and it leaves the point at the right
+indentation column for the code. Thus you can write code inside macros
+almost exactly as you can elsewhere, without having to bother with the
+trailing backslashes.
+
+
+@comment !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+@node Font Locking, Commands, Macro Handling, Top
+@comment node-name, next, previous, up
+@chapter Font Locking
+@cindex font locking
+@comment !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+
+@strong{Please note:} The font locking in AWK mode is currently not integrated
+with the rest of @ccmode{}, so this section does not apply there.
+@xref{AWK Mode Font Locking}, instead.
+
+@cindex Font Lock mode
+
+@ccmode{} provides font locking for its supported languages by supplying
+patterns for use with Font Lock mode. This means that you get distinct
+faces on the various syntactic parts such as comments, strings, keywords
+and types, which is very helpful in telling them apart at a glance and
+discovering syntactic errors. @xref{Font Lock,,, emacs, The Emacs
+Editor}, for ways to enable font locking in @ccmode{} buffers.
+
+@menu
+* Font Locking Preliminaries::
+* Faces::
+* Documentation Comments::
+@end menu
+
+
+@comment !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+@node Font Locking Preliminaries, Faces, , Font Locking
+@comment node-name, next, previous, up
+@section Font Locking Preliminaries
+@comment !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+
+The font locking for most of the @ccmode{} languages were provided
+directly by the Font Lock package prior to version 5.30 of @ccmode{}.
+In the transition to @ccmode{} 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 pecularities 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 @ccmode{} 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. @ccmode{} 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 @code{font-lock-maximum-decoration}.
+
+@vindex font-lock-maximum-decoration
+
+The decoration levels are used as follows:
+
+@enumerate
+@comment 1
+@item
+Minimal font locking: Fontify only comments, strings and preprocessor
+directives (in the languages that use cpp).
+
+@comment 2
+@item
+Fast normal font locking: In addition to level 1, fontify keywords,
+simple types and declarations that are easy to recognize. The variables
+@code{*-font-lock-extra-types} (where @samp{*} is the name of the
+language) are used to recognize types (see below). Documentation
+comments like Javadoc are fontified according to
+@code{c-doc-comment-style} (@pxref{Documentation 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.
+
+@comment 3
+@item
+Accurate normal font locking: Like level 2 but uses a different approach
+that can recognize types and declarations much more accurately. The
+@code{*-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.
+
+@cindex Lazy Lock mode
+@cindex Just-in-time Lock mode
+
+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.
+@end enumerate
+
+@cindex user defined types
+@cindex types, user defined
+
+Since user defined types are hard to recognize you can provide
+additional regexps to match those you use:
+
+@defopt c-font-lock-extra-types
+@defoptx c++-font-lock-extra-types
+@defoptx objc-font-lock-extra-types
+@defoptx java-font-lock-extra-types
+@defoptx idl-font-lock-extra-types
+@defoptx pike-font-lock-extra-types
+For each language there's a variable @code{*-font-lock-extra-types},
+where @samp{*} stands for the language in question. It contains a list
+of regexps that matches identifiers that should be recognized as types,
+e.g., @samp{\\sw+_t} to recognize all identifiers ending with @samp{_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 @samp{_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 @ccmode{} needs to
+recognize types.
+@end defopt
+
+
+@comment !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+@node Faces, Documentation Comments, Font Locking Preliminaries, Font Locking
+@comment node-name, next, previous, up
+@section Faces
+@cindex faces
+@comment !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+
+@ccmode{} attempts to use the standard faces for programming languages
+in accordance with their intended purposes as far as possible. No extra
+faces are currently provided, with the exception of a replacement face
+@code{c-invalid-face} for emacsen that don't provide
+@code{font-lock-warning-face}.
+
+@itemize @bullet
+@item
+@vindex font-lock-comment-face
+Normal comments are fontified in @code{font-lock-comment-face}.
+
+@item
+@vindex font-lock-doc-face
+@vindex font-lock-doc-string-face
+@vindex font-lock-comment-face
+Comments that are recognized as documentation (@pxref{Documentation
+Comments}) get @code{font-lock-doc-face} (Emacs) or
+@code{font-lock-doc-string-face} (XEmacs) if those faces exist. If they
+don't then @code{font-lock-comment-face} is used.
+
+@item
+@vindex font-lock-string-face
+String and character literals are fontified in
+@code{font-lock-string-face}.
+
+@item
+@vindex font-lock-keyword-face
+Keywords are fontified with @code{font-lock-keyword-face}.
+
+@item
+@vindex font-lock-function-name-face
+@code{font-lock-function-name-face} is used for function names in
+declarations and definitions, and classes in those contexts. It's also
+used for preprocessor defines with arguments.
+
+@item
+@vindex font-lock-variable-name-face
+Variables in declarations and definitions, and other identifiers in such
+variable contexts, get @code{font-lock-variable-name-face}. It's also
+used for preprocessor defines without arguments.
+
+@item
+@vindex font-lock-constant-face
+@vindex font-lock-reference-face
+Builtin constants are fontified in @code{font-lock-constant-face} if it
+exists, @code{font-lock-reference-face} otherwise. As opposed to the
+preceding two faces, this is used on the names in expressions, and it's
+not used in declarations, even if there happen to be a @samp{const} in
+them somewhere.
+
+@item
+@vindex font-lock-type-face
+@code{font-lock-type-face} is put on types (both predefined and user
+defined) and classes in type contexts.
+
+@item
+@vindex font-lock-constant-face
+@vindex font-lock-reference-face
+Label identifiers get @code{font-lock-constant-face} if it exists,
+@code{font-lock-reference-face} otherwise.
+
+@item
+Name qualifiers and identifiers for scope constructs are fontified like
+labels.
+
+@item
+Special markup inside documentation comments are also fontified like
+labels.
+
+@item
+@vindex font-lock-preprocessor-face
+@vindex font-lock-builtin-face
+@vindex font-lock-reference-face
+Preprocessor directives get @code{font-lock-preprocessor-face} if it
+exists (i.e., XEmacs). In Emacs they get @code{font-lock-builtin-face}
+or @code{font-lock-reference-face}, for lack of a closer equivalent.
+
+@item
+@vindex font-lock-warning-face
+@vindex c-invalid-face
+@vindex invalid-face (c-)
+Some kinds of syntactic errors are fontified with
+@code{font-lock-warning-face} in Emacs. In older XEmacs versions
+there's no corresponding standard face, so there a special
+@code{c-invalid-face} is used, which is defined to stand out sharply by
+default.
+
+Note that it's not used for @samp{#error} or @samp{#warning} directives,
+since those aren't syntactic errors in themselves.
+@end itemize
+
+
+@comment !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+@node Documentation Comments, , Faces, Font Locking
+@comment node-name, next, previous, up
+@section Documentation Comments
+@cindex documentation comments
+@comment !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
+
+There are various tools to supply documentation in the source as
+specially structured comments, e.g., the standard Javadoc tool in Java.
+@ccmode{} provides an extensible mechanism to fontify such comments and
+the special markup inside them.
+
+@defopt c-doc-comment-style
+@vindex doc-comment-style (c-)
+This is a style variable that specifies which documentation comment
+style to recognize, e.g., @code{javadoc} for Javadoc comments.
+
+The value may also be a list of styles, in which case all of them are
+recognized simultaneously (presumably with markup cues that don't
+conflict).
+
+The value may also be an association list to specify different comment
+styles for different languages. The symbol for the major mode is then
+looked up in the alist, and the value of that element is interpreted as
+above if found. If it isn't found then the symbol `other' is looked up
+and its value is used instead.
+
+Note that @ccmode{} uses this variable to set other variables that
+handle fontification etc. That's done at mode initialization or when
+you switch to a style which sets this variable. Thus, if you change it
+in some other way, e.g., interactively in a CC Mode buffer, you will need
+to do @kbd{M-x java-mode} (or whatever mode you're currently using) to
+reinitialize.
+
+@findex c-setup-doc-comment-style
+@findex setup-doc-comment-style (c-)
+Note also that when @ccmode{} starts up, the other variables are
+modified before the mode hooks are run. If you change this variable in
+a mode hook, you have to call @code{c-setup-doc-comment-style}
+afterwards to redo that work.
+@end defopt
+
+@ccmode{} currently provides handing of the following doc comment
+styles: