root/branches/2.1/info/ccmode-1

This is ../info/ccmode, produced by makeinfo version 4.2 from
cc-mode.texi.

INFO-DIR-SECTION Emacs
START-INFO-DIR-ENTRY
* CC Mode: (ccmode).   Emacs mode for editing C, C++, Objective-C,
                          Java, Pike, and IDL code.
END-INFO-DIR-ENTRY

   Copyright (C) 1995, 96, 97, 98, 99, 2000, 2001 Free Software
Foundation, Inc.

   Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1 or
any later version published by the Free Software Foundation; with the
Invariant Sections being "The GNU Manifesto", "Distribution" and "GNU
GENERAL PUBLIC LICENSE", with the Front-Cover texts being "A GNU
Manual", and with the Back-Cover Texts as in (a) below.  A copy of the
license is included in the section entitled "GNU Free Documentation
License" in the Emacs manual.

   (a) The FSF's Back-Cover Text is: "You have freedom to copy and
modify this GNU Manual, like GNU software.  Copies published by the Free
Software Foundation raise funds for GNU development."

   This document is part of a collection distributed under the GNU Free
Documentation License.  If you want to distribute this document
separately from the collection, you can do so by adding a copy of the
license to the document, as described in section 6 of the license.


File: ccmode,  Node: Top,  Next: Introduction,  Prev: (dir),  Up: (dir)

CC Mode
*******

   CC Mode is a GNU Emacs mode for editing files containing C, C++,
Objective-C, Java, CORBA IDL, and Pike code.  It provides syntax-based
indentation and has several handy commands and some minor modes to make
the editing easier.  Note that CC Mode does _not_ provide font-locking;
there are other Emacs packages for that.

* Menu:

* Introduction::
* Getting Connected::
* New Indentation Engine::
* Minor Modes::
* Text Filling and Line Breaking::
* Commands::
* Customizing Indentation::
* Syntactic Symbols::
* Indentation Functions::
* Performance Issues::
* Limitations and Known Bugs::
* Frequently Asked Questions::
* Getting the Latest CC Mode Release::
* Mailing Lists and Submitting Bug Reports::
* Sample .emacs File::

 --- Indices ---

* Concept Index::
* Command Index::
* Key Index::
* Variable Index::

 --- The Detailed Node Listing ---

New Indentation Engine

* Syntactic Analysis::
* Indentation Calculation::

Minor Modes

* Auto-newline Insertion::
* Hungry-deletion of Whitespace::

Auto-newline Insertion

* Hanging Braces::
* Hanging Colons::
* Hanging Semi-colons and Commas::
* Other Electric Commands::
* Clean-ups::

Commands

* Indentation Commands::
* Movement Commands::
* Other Commands::

Customizing Indentation

* Interactive Customization::
* Permanent Customization::
* Hooks::
* Styles::
* Advanced Customizations::

Styles

* Built-in Styles::
* Adding Styles::
* File Styles::

Advanced Customizations

* Custom Indentation Functions::
* Custom Brace and Colon Hanging::
* Customizing Semi-colons and Commas::
* Other Special Indentations::


File: ccmode,  Node: Introduction,  Next: Getting Connected,  Prev: Top,  Up: Top

Introduction
************

   Welcome to CC Mode, a GNU Emacs mode for editing files containing C,
C++, Objective-C, Java, CORBA IDL, and Pike code.  This incarnation of
the mode is descendant from `c-mode.el' (also called "Boring Old C
Mode" or BOCM :-), and `c++-mode.el' version 2, which Barry has been
maintaining since 1992.  CC Mode represents a significant milestone in
the mode's life.  It has been fully merged back with Emacs 19's
`c-mode.el'. Also a new, more intuitive and flexible mechanism for
controlling indentation has been developed.  Late in 1997, Martin
joined the CC Mode Maintainers Team, and implemented the Pike support.
As of 2000 Martin has taken over as the sole maintainer.

   This manual describes CC Mode version 5.28.

   CC Mode supports the editing of K&R and ANSI C, "ARM" (1) C++,
Objective-C, Java, CORBA's Interface Definition Language, and Pike(2)
files.  In this way, you can easily set up consistent coding styles for
use in editing all of these languages.  CC Mode does _not_ handle
font-locking (a.k.a. syntax coloring, keyword highlighting) or anything
of that nature, for any of these modes.  Font-locking is handled by
other Emacs packages.

   This manual will describe the following:

   * How to get started using CC Mode.

   * How the new indentation engine works.

   * How to customize the new indentation engine.


   Note that the name of this package is "CC Mode," but there is no top
level `cc-mode' entry point.  All of the variables, commands, and
functions in CC Mode are prefixed with `c-<THING>', and `c-mode',
`c++-mode', `objc-mode', `java-mode', `idl-mode', and `pike-mode' entry
points are provided.  This package is intended to be a replacement for
`c-mode.el' and `c++-mode.el'.

   This distribution also contains a file called `cc-compat.el' which
should ease your transition from BOCM to CC Mode.  If you have a BOCM
configuration you are really happy with, and want to postpone learning
how to configure CC Mode, take a look at that file.  It maps BOCM
configuration variables to CC Mode's new indentation model.  It is not
actively supported so for the long run, you should learn how to
customize CC Mode to support your coding style.

   A special word of thanks goes to Krishna Padmasola for his work in
converting the original `README' file to Texinfo format.  I'd also like
to thank all the CC Mode victims who help enormously during the early
beta stages of CC Mode's development.

   ---------- Footnotes ----------

   (1) `The Annotated C++ Reference Manual', by Ellis and Stroustrup.

   (2) A C-like scripting language with its roots in the LPC language
used in some MUD engines.  See `http://pike.idonex.se/'.


File: ccmode,  Node: Getting Connected,  Next: New Indentation Engine,  Prev: Introduction,  Up: Top

Getting Connected
*****************

   If you got this version of CC Mode with Emacs or XEmacs, it should
work just fine right out of the box.  Note however that you may not have
the latest CC Mode release and may want to upgrade your copy.

   If you are upgrading an existing CC Mode installation, please see the
`README' file for installation details.  CC Mode may not work with
older versions of Emacs or XEmacs.  See the CC Mode release notes Web
pages for the latest information on Emacs version and package
compatibility (*note Getting the Latest CC Mode Release::).

   _Note that CC Mode no longer works with Emacs 18!_, so if you
haven't upgraded from Emacs 18 by now, you are out of luck.

   You can find out what version of CC Mode you are using by visiting a
C file and entering `M-x c-version RET'.  You should see this message in
the echo area:

     Using CC Mode version 5.XX

where `XX' is the minor release number.


File: ccmode,  Node: New Indentation Engine,  Next: Minor Modes,  Prev: Getting Connected,  Up: Top

New Indentation Engine
**********************

   CC Mode has a new indentation engine, providing a simplified, yet
flexible and general mechanism for customizing indentation. It separates
indentation calculation into two steps: first, CC Mode analyzes the
line of code being indented to determine the kind of language construct
it's looking at, then it applies user defined offsets to the current
line based on this analysis.

   This section will briefly cover how indentation is calculated in CC
Mode. It is important to understand the indentation model being used so
that you will know how to customize CC Mode for your personal coding
style.

* Menu:

* Syntactic Analysis::
* Indentation Calculation::


File: ccmode,  Node: Syntactic Analysis,  Next: Indentation Calculation,  Up: New Indentation Engine

Syntactic Analysis
==================

   The first thing CC Mode does when indenting a line of code, is to
analyze the line, determining the "syntactic component list" of the
construct on that line.  A syntactic component consists of a pair of
information (in lisp parlance, a _cons cell_), where the first part is
a "syntactic symbol", and the second part is a "relative buffer
position".  Syntactic symbols describe elements of C code (1), e.g.
`statement', `substatement', `class-open', `class-close', etc.  *Note
Syntactic Symbols::, for a complete list of currently recognized
syntactic symbols and their semantics.  The style variable
`c-offsets-alist' also contains the list of currently supported
syntactic symbols.

   Conceptually, a line of C code is always indented relative to the
indentation of some line higher up in the buffer.  This is represented
by the relative buffer position in the syntactic component.

   Here is an example.  Suppose we had the following code as the only
thing in a C++ buffer (2):

       1: void swap( int& a, int& b )
       2: {
       3:     int tmp = a;
       4:     a = b;
       5:     b = tmp;
       6: }

   We can use the command `C-c C-s' (`c-show-syntactic-information') to
simply report what the syntactic analysis is for the current line.
Running this command on line 4 of this example, we'd see in the echo
area(3):

     ((statement . 35))

   This tells us that the line is a statement and it is indented
relative to buffer position 35, which happens to be the `i' in `int' on
line 3.  If you were to move point to line 3 and hit `C-c C-s', you
would see:

     ((defun-block-intro . 29))

   This indicates that the `int' line is the first statement in a top
level function block, and is indented relative to buffer position 29,
which is the brace just after the function header.

   Here's another example:

       1: int add( int val, int incr, int doit )
       2: {
       3:     if( doit )
       4:         {
       5:             return( val + incr );
       6:         }
       7:     return( val );
       8: }

Hitting `C-c C-s' on line 4 gives us:

     ((substatement-open . 46))

which tells us that this is a brace that _opens_ a substatement block.
(4)

   Syntactic component lists can contain more than one component, and
individual syntactic components need not have relative buffer positions.
The most common example of this is a line that contains a "comment only
line".

       1: void draw_list( List<Drawables>& drawables )
       2: {
       3:         // call the virtual draw() method on each element in list
       4:     for( int i=0; i < drawables.count(), ++i )
       5:     {
       6:         drawables[i].draw();
       7:     }
       8: }

Hitting `C-c C-s' on line 3 of this example gives:

     ((comment-intro) (defun-block-intro . 46))

and you can see that the syntactic component list contains two syntactic
components.  Also notice that the first component, `(comment-intro)'
has no relative buffer position.

   ---------- Footnotes ----------

   (1) Unless otherwise noted, the term "C code" to refers to all the
C-like languages.

   (2) The line numbers in this and future examples don't actually
appear in the buffer, of course!

   (3) With a universal argument (i.e. `C-u C-c C-s') the analysis is
inserted into the buffer as a comment on the current line.

   (4) A "substatement" is the line after a conditional statement, such
as `if', `else', `while', `do', `switch', etc.  A "substatement block"
is a brace block following one of these conditional statements.


File: ccmode,  Node: Indentation Calculation,  Prev: Syntactic Analysis,  Up: New Indentation Engine

Indentation Calculation
=======================

   Indentation for a line is calculated using the syntactic component
list derived in step 1 above (*note Syntactic Analysis::).  Each
component contributes to the final total indentation of the line in two
ways.

   First, the syntactic symbols are looked up in the `c-offsets-alist'
style variable, which is an association list of syntactic symbols and
the offsets to apply for those symbols.  These offsets are added to a
running total.

   Second, if the component has a relative buffer position, CC Mode
adds the column number of that position to the running total.  By adding
up the offsets and columns for every syntactic component on the list,
the final total indentation for the current line is computed.

   Let's use our two code examples above to see how this works.  Here is
our first example again:

         1: void swap( int& a, int& b )
         2: {
         3:     int tmp = a;
         4:     a = b;
         5:     b = tmp;
         6: }

   Let's say point is on line 3 and we hit the `TAB' key to re-indent
the line.  Remember that the syntactic component list for that line is:

     ((defun-block-intro . 29))

CC Mode looks up `defun-block-intro' in the `c-offsets-alist' style
variable.  Let's say it finds the value `4'; it adds this to the
running total (initialized to zero), yielding a running total
indentation of 4 spaces.

   Next CC Mode goes to buffer position 29 and asks for the current
column.  This brace is in column zero, so CC Mode adds `0' to the
running total.  Since there is only one syntactic component on the list
for this line, indentation calculation is complete, and the total
indentation for the line is 4 spaces.

   Here's another example:

         1: int add( int val, int incr, int doit )
         2: {
         3:     if( doit )
         4:         {
         5:             return( val + incr );
         6:         }
         7:     return( val );
         8: }

   If we were to hit `TAB' on line 4 in the above example, the same
basic process is performed, despite the differences in the syntactic
component list.  Remember that the list for this line is:

     ((substatement-open . 46))

   Here, CC Mode first looks up the `substatement-open' symbol in
`c-offsets-alist'. Let's say it finds the value `4'.  This yields a
running total of 4.  CC Mode then goes to buffer position 46, which is
the `i' in `if' on line 3.  This character is in the fourth column on
that line so adding this to the running total yields an indentation for
the line of 8 spaces.

   Simple, huh?

   Actually, the mode usually just does The Right Thing without you
having to think about it in this much detail.  But when customizing
indentation, it's helpful to understand the general indentation model
being used.

   As you configure CC Mode, you might want to set the variable
`c-echo-syntactic-information-p' to non-`nil' so that the syntactic
component list and calculated offset will always be echoed in the
minibuffer when you hit `TAB'.


File: ccmode,  Node: Minor Modes,  Next: Text Filling and Line Breaking,  Prev: New Indentation Engine,  Up: Top

Minor Modes
***********

   CC Mode contains two minor-mode-like features that you should find
useful while you enter new C code.  The first is called "auto-newline"
mode, and the second is called "hungry-delete" mode.  These minor modes
can be toggled on and off independently, and CC Mode can be configured
so that it starts up with any combination of these minor modes.  By
default, both of these minor modes are turned off.

   The state of the minor modes is always reflected in the minor mode
list on the modeline of the CC Mode buffer.  When auto-newline mode is
enabled, you will see `C/a' on the mode line (1).  When hungry delete
mode is enabled you would see `C/h' and when both modes are enabled,
you'd see `C/ah'.

   CC Mode provides key bindings which allow you to toggle the minor
modes on the fly while editing code.  To toggle just the auto-newline
state, hit `C-c C-a' (`c-toggle-auto-state').  When you do this, you
should see the `a' indicator either appear or disappear on the
modeline.  Similarly, to toggle just the hungry-delete state, use `C-c
C-d' (`c-toggle-hungry-state'), and to toggle both states, use `C-c
C-t' (`c-toggle-auto-hungry-state').

   To set up the auto-newline and hungry-delete states to your preferred
values, you would need to add some lisp to your `.emacs' file that
called one of the `c-toggle-*-state' functions directly.  When called
programmatically, each function takes a numeric value, where a positive
number enables the minor mode, a negative number disables the mode, and
zero toggles the current state of the mode.

   So for example, if you wanted to enable both auto-newline and
hungry-delete for all your C file editing, you could add the following
to your `.emacs' file:

     (add-hook 'c-mode-common-hook
          (lambda () (c-toggle-auto-hungry-state 1)))

* Menu:

* Auto-newline Insertion::
* Hungry-deletion of Whitespace::

   ---------- Footnotes ----------

   (1) The `C' would be replaced with `C++', `ObjC', `Java', `IDL', or
`Pike' for the respective languages.


File: ccmode,  Node: Auto-newline Insertion,  Next: Hungry-deletion of Whitespace,  Up: Minor Modes

Auto-newline Insertion
======================

   Auto-newline minor mode works by enabling certain "electric
commands".  Electric commands are typically bound to special characters
such as the left and right braces, colons, semi-colons, etc., which when
typed, perform some magic formatting in addition to inserting the typed
character.  As a general rule, electric commands are only electric when
the following conditions apply:

   * Auto-newline minor mode is enabled, as evidenced by a `C/a' or
     `C/ah' indicator on the modeline.

   * The character was not typed inside of a literal (1).

   * No numeric argument was supplied to the command (i.e. it was typed
     as normal, with no `C-u' prefix).


* Menu:

* Hanging Braces::
* Hanging Colons::
* Hanging Semi-colons and Commas::
* Other Electric Commands::
* Clean-ups::

   ---------- Footnotes ----------

   (1) A "literal" is defined as any comment, string, or C preprocessor
macro definition.  These constructs are also known as "syntactic
whitespace" since they are usually ignored when scanning C code.


File: ccmode,  Node: Hanging Braces,  Next: Hanging Colons,  Up: Auto-newline Insertion

Hanging Braces
--------------

   When you type either an open or close brace (i.e. `{' or `}'), the
electric command `c-electric-brace' gets run.  This command has two
electric formatting behaviors.  First, it will perform some
re-indentation of the line the brace was typed on, and second, it will
add various newlines before and/or after the typed brace.
Re-indentation occurs automatically whenever the electric behavior is
enabled.  If the brace ends up on a line other than the one it was typed
on, then that line is also re-indented.

   The default in auto-newline mode is to insert newlines both before
and after a brace, but that can be controlled by the
`c-hanging-braces-alist' style variable.  This variable contains a
mapping between syntactic symbols related to braces, and a list of
places to insert a newline.  The syntactic symbols that are useful for
this list are: `class-open', `class-close', `defun-open',
`defun-close', `inline-open', `inline-close', `brace-list-open',
`brace-list-close', `brace-list-intro', `brace-entry-open',
`block-open', `block-close', `substatement-open',
`statement-case-open', `extern-lang-open', `extern-lang-close',
`namespace-open', `namespace-close', `inexpr-class-open', and
`inexpr-class-close'(1).  *Note Syntactic Symbols::, for a more detailed
description of these syntactic symbols, except for `inexpr-class-open'
and `inexpr-class-close', which aren't actual syntactic symbols.

   The braces of anonymous inner classes in Java are given the special
symbols `inexpr-class-open' and `inexpr-class-close', so that they can
be distinguished from the braces of normal classes(2).

   The value associated with each syntactic symbol in this association
list is called an ACTION which can be either a function or a list.
*Note Custom Brace and Colon Hanging::, for a more detailed discussion
of using a function as a brace hanging ACTION.

   When the ACTION is a list, it can contain any combination of the
symbols `before' and `after', directing CC Mode where to put newlines
in relationship to the brace being inserted.  Thus, if the list
contains only the symbol `after', then the brace is said to "hang" on
the right side of the line, as in:

     // here, open braces always `hang'
     void spam( int i ) {
         if( i == 7 ) {
             dosomething(i);
         }
     }

   When the list contains both `after' and `before', the braces will
appear on a line by themselves, as shown by the close braces in the
above example.  The list can also be empty, in which case no newlines
are added either before or after the brace.

   If a syntactic symbol is missing entirely from
`c-hanging-braces-alist', it's treated in the same way as an ACTION
with a list containing `before' and `after', so that braces by default
end up on their own line.

   For example, the default value of `c-hanging-braces-alist' is:

       ((brace-list-open)
        (brace-entry-open)
        (substatement-open after)
        (block-close . c-snug-do-while)
        (extern-lang-open after)
        (inexpr-class-open after)
        (inexpr-class-close before))

which says that `brace-list-open' and `brace-entry-open' braces should
both hang on the right side, and allow subsequent text to follow on the
same line as the brace.  Also, `substatement-open', `extern-lang-open',
and `inexpr-class-open' braces should hang on the right side, but
subsequent text should follow on the next line.  The opposite holds for
`inexpr-class-close' braces; they won't hang, but the following text
continues on the same line.  Here, in the `block-close' entry, you also
see an example of using a function as an ACTION.  In all other cases,
braces are put on a line by themselves.

   A word of caution: it is not a good idea to hang top-level construct
introducing braces, such as `class-open' or `defun-open'.  Emacs makes
an assumption that such braces will always appear in column zero,
hanging them can introduce performance problems.  *Note Performance
Issues::, for more information.

   ---------- Footnotes ----------

   (1) Note that the aggregate constructs in Pike mode, `({', `})',
`([', `])', and `(<', `>)', do not count as brace lists in this regard,
even though they do for normal indentation purposes.  It's currently
not possible to set automatic newlines on these constructs.

   (2) The braces of anonymous classes produces a combination of
`inexpr-class', and `class-open' or `class-close' in normal indentation
analysis.


File: ccmode,  Node: Hanging Colons,  Next: Hanging Semi-colons and Commas,  Prev: Hanging Braces,  Up: Auto-newline Insertion

Hanging Colons
--------------

   Using a mechanism similar to brace hanging (*note Hanging Braces::),
colons can also be made to hang using the style variable
`c-hanging-colons-alist'.  The syntactic symbols appropriate for this
association list are: `case-label', `label', `access-label',
`member-init-intro', and `inher-intro'.  Note however that for
`c-hanging-colons-alist', ACTIONs as functions are not supported. See
also *Note Custom Brace and Colon Hanging:: for details.

   In C++, double-colons are used as a scope operator but because these
colons always appear right next to each other, newlines before and after
them are controlled by a different mechanism, called "clean-ups" in CC
Mode.  *Note Clean-ups::, for details.


File: ccmode,  Node: Hanging Semi-colons and Commas,  Next: Other Electric Commands,  Prev: Hanging Colons,  Up: Auto-newline Insertion

Hanging Semi-colons and Commas
------------------------------

   Semicolons and commas are also electric in CC Mode, but since these
characters do not correspond directly to syntactic symbols, a different
mechanism is used to determine whether newlines should be automatically
inserted after these characters.  *Note Customizing Semi-colons and
Commas::, for details.


File: ccmode,  Node: Other Electric Commands,  Next: Clean-ups,  Prev: Hanging Semi-colons and Commas,  Up: Auto-newline Insertion

Other Electric Commands
-----------------------

   A few other keys also provide electric behavior.  For example `#'
(`c-electric-pound') is electric when typed as the first non-whitespace
character on a line.  In this case, the variable
`c-electric-pound-behavior' is consulted for the electric behavior.
This variable takes a list value, although the only element currently
defined is `alignleft', which tells this command to force the `#'
character into column zero.  This is useful for entering C preprocessor
macro definitions.

   Stars and slashes (i.e. `*' and `/', `c-electric-star' and
`c-electric-slash' respectively) are also electric under certain
circumstances.  If a star is inserted as the second character of a C
style block comment on a comment-only line, then the comment delimiter
is indented as defined by `c-offsets-alist'.  A comment-only line is
defined as a line which contains only a comment, as in:

     void spam( int i )
     {
             // this is a comment-only line...
         if( i == 7 )                             // but this is not
         {
             dosomething(i);
         }
     }

   Likewise, if a slash is inserted as the second slash in a C++ style
line comment (also only on a comment-only line), then the line is
indented as defined by `c-offsets-alist'.

   Less-than and greater-than signs (`c-electric-lt-gt') are also
electric, but only in C++ mode.  Hitting the second of two `<' or `>'
keys re-indents the line if it is a C++ style stream operator.

   The normal parenthesis characters `(' and `)' also reindent the
current line if they are used in normal code.  This is useful for
getting the closing parenthesis of an argument list aligned
automatically.


File: ccmode,  Node: Clean-ups,  Prev: Other Electric Commands,  Up: Auto-newline Insertion

Clean-ups
---------

   "Clean-ups" are mechanisms complementary to colon and brace hanging.
On the surface, it would seem that clean-ups overlap the functionality
provided by the `c-hanging-*-alist' variables.  Clean-ups are however
used to adjust code "after-the-fact," i.e. to adjust the whitespace in
constructs after they are typed.

   Most of the clean-ups are only applicable to counteract automatically
inserted newlines, and will therefore only have any effect if the
auto-newline minor mode is turned on.  Others will work all the time.

   You can configure CC Mode's clean-ups by setting the style variable
`c-cleanup-list', which is a list of clean-up symbols.  By default, CC
Mode cleans up only the `scope-operator' construct, which is necessary
for proper C++ support.  Note that clean-ups are only performed when
the construct does not occur within a literal (*note Auto-newline
Insertion::), and when there is nothing but whitespace appearing
between the individual components of the construct.

   These are the clean-ups that only are active in the auto-newline
minor mode:

   * `brace-else-brace' -- Clean up `} else {' constructs by placing
     the entire construct on a single line.  Clean-up occurs when the
     open brace after the `else' is typed.  So for example, this:

          void spam(int i)
          {
              if( i==7 )
              {
                  dosomething();
              }
              else
              {

     appears like this after the open brace is typed:

          void spam(int i)
          {
              if( i==7 ) {
                  dosomething();
              } else {

   * `brace-elseif-brace' -- Similar to the `brace-else-brace'
     clean-up, but this cleans up `} else if (...) {' constructs.  For
     example:

          void spam(int i)
          {
              if( i==7 )
              {
                  dosomething();
              }
              else if( i==3 )
              {

     appears like this after the open parenthesis is typed:

          void spam(int i)
          {
              if( i==7 ) {
                  dosomething();
              } else if( i==3 )
              {

     and like this after the open brace is typed:

          void spam(int i)
          {
              if( i==7 ) {
                  dosomething();
              } else if( i==3 ) {

   * `brace-catch-brace' -- Analogous to `brace-elseif-brace', but
     cleans up `} catch (...) {' in C++ and Java mode.

   * `empty-defun-braces' -- Clean up braces following a top-level
     function or class definition that contains no body.  Clean up
     occurs when the closing brace is typed.  Thus the following:

          class Spam
          {
          }

     is transformed into this when the close brace is typed:

          class Spam
          {}

   * `defun-close-semi' -- Clean up the terminating semi-colon on
     top-level function or class definitions when they follow a close
     brace.  Clean up occurs when the semi-colon is typed.  So for
     example, the following:

          class Spam
          {
          }
          ;

     is transformed into this when the semi-colon is typed:


          class Spam
          {
          };

   * `list-close-comma' -- Clean up commas following braces in array
     and aggregate initializers.  Clean up occurs when the comma is
     typed.

   * `scope-operator' -- Clean up double colons which may designate a
     C++ scope operator split across multiple lines(1).  Clean up
     occurs when the second colon is typed.  You will always want
     `scope-operator' in the `c-cleanup-list' when you are editing C++
     code.


   The following clean-ups are always active when they occur on
`c-cleanup-list', and are thus not affected by the auto-newline minor
mode:

   * `space-before-funcall' -- Insert a space between the function name
     and the opening parenthesis of a function call.  This produces
     function calls in the style mandated by the GNU coding standards,
     e.g. `signal (SIGINT, SIG_IGN)' and `abort ()'.  Clean up occurs
     when the opening parenthesis is typed.

   * `compact-empty-funcall' -- Clean up any space between the function
     name and the opening parenthesis of a function call that have no
     arguments.  This is typically used together with
     `space-before-funcall' if you prefer the GNU function call style
     for functions with arguments but think it looks ugly when it's
     only an empty parenthesis pair.  I.e. you will get `signal (SIGINT,
     SIG_IGN)', but `abort()'.  Clean up occurs when the closing
     parenthesis is typed.


   ---------- Footnotes ----------

   (1) Certain C++ constructs introduce ambiguous situations, so
`scope-operator' clean-ups may not always be correct.  This usually
only occurs when scoped identifiers appear in switch label tags.


File: ccmode,  Node: Hungry-deletion of Whitespace,  Prev: Auto-newline Insertion,  Up: Minor Modes

Hungry-deletion of Whitespace
=============================

   Hungry deletion of whitespace, or as it more commonly called,
"hungry-delete mode", is a simple feature that some people find
extremely useful.  In fact, you might find yourself wanting
hungry-delete in *all* your editing modes!

   In a nutshell, when hungry-delete mode is enabled, hitting the
<Backspace> key(1) will consume all preceding whitespace, including
newlines and tabs.  This can really cut down on the number of
<Backspace>'s you have to type if, for example you made a mistake on
the preceding line.

   By default, when you hit the <Backspace> key CC Mode runs the
command `c-electric-backspace', which deletes text in the backwards
direction.  When deleting a single character, or when <Backspace> is
hit in a literal (*note Auto-newline Insertion::), or when hungry-delete
mode is disabled, the function contained in the `c-backspace-function'
variable is called with one argument (the number of characters to
delete).  This variable is set to `backward-delete-char-untabify' by
default.

   The default behavior of the <Delete> key depends on the flavor of
Emacs you are using.  By default in XEmacs 20.3 and beyond, the
<Delete> key is bound to `c-electric-delete'.  You control the
direction that the <Delete> key deletes by setting the variable
`delete-key-deletes-forward', a standard XEmacs variable.  When this
variable is non-`nil' and hungry-delete mode is enabled,
`c-electric-delete' will consume all whitespace _following_ point.
When `delete-key-deletes-forward' is `nil', it deletes all whitespace
_preceding_ point(2)  When deleting a single character, or if <Delete>
is hit in a literal, or hungry-delete mode is disabled, the function
contained in `c-delete-function' is called with one argument: the
number of characters to delete.  This variable is set to `delete-char'
by default.

   In Emacs 19 or Emacs 20, both the <Delete> and <Backspace> keys are
bound to `c-electric-backspace', however you can change this by
explicitly binding `[delete]'(3).

   XEmacsen older than 20.3 behave similar to Emacs 19 and Emacs 20.

   ---------- Footnotes ----------

   (1) I say "hit the <Backspace> key" but what I really mean is "when
Emacs receives the `BackSpace' key event."  The difference usually
isn't significant to most users, but advanced users will realize that
under window systems such as X, any physical key (keycap) on the
keyboard can be configured to generate any keysym, and thus any Emacs
key event.  Also, the use of Emacs on TTYs will affect which keycap
generates which key event.  From a pedantic point of view, here we are
only concerned with the key event that Emacs receives.

   (2) i.e. it literally calls `c-electric-backspace'.

   (3) E.g. to `c-electric-delete' in your `.emacs' file.  Note
however, that Emacs 20 does not have a standard variable such as
`delete-key-deletes-forward'.


File: ccmode,  Node: Text Filling and Line Breaking,  Next: Commands,  Prev: Minor Modes,  Up: Top

Text Filling and Line Breaking
******************************

   Since there's a lot of normal text in comments and string literals,
CC Mode provides features to edit these like in text mode.  The goal is
to do it as seamlessly as possible, i.e. you can use auto fill mode,
sentence and paragraph movement, paragraph filling, adaptive filling etc
wherever there's a piece of normal text without having to think much
about it.  CC Mode should keep the indentation, fix the comment line
decorations, and so on, for you.  It does that by hooking in on the
different line breaking functions and tuning relevant variables as
necessary.

   To make Emacs recognize comments and treat text in them as normal
paragraphs, CC Mode makes several standard variables(1) buffer local
and modifies them according to the language syntax and the style of
line decoration that starts every line in a comment.  The style variable
`c-comment-prefix-regexp' contains the regexp used to recognize this
"comment line prefix".  The default is `//+\\|\\**', which matches C++
style line comments like

     // blah blah

with two or more slashes in front of them, and C style block comments
like

     /*
      * blah blah
      */

with zero or more stars at the beginning of every line.  If you change
that variable, please make sure it still matches the comment starter
(i.e. `//') of line comments _and_ the line prefix inside block
comments.  Also note that since CC Mode uses the value of
`c-comment-prefix-regexp' to set up several other variables at mode
initialization, you need to reinitialize the program mode if you change
it inside a CC Mode buffer.

   Line breaks are by default handled (almost) the same regardless
whether they are made by auto fill mode (*note Auto Fill: (emacs)Auto
Fill.), paragraph filling (e.g. with `M-q'), or explicitly with `M-j'
or similar methods.  In string literals, the new line gets the same
indentation as the previous nonempty line (may be changed with the
`string' syntactic symbol).  In comments, CC Mode uses
`c-comment-prefix-regexp' to adapt the line prefix from the other lines
in the comment.

   CC Mode uses adaptive fill mode (*note Adaptive Fill:
(emacs)Adaptive Fill.) to make Emacs correctly keep the line prefix
when filling paragraphs.  That also makes Emacs preserve the text
indentation _inside_ the comment line prefix.  E.g. in the following
comment, both paragraphs will be filled with the left margins kept
intact:

     /* Make a balanced b-tree of the nodes in the incoming
      * stream.  But, to quote the famous words of Donald E.
      * Knuth,
      *
      *     Beware of bugs in the above code; I have only
      *     proved it correct, not tried it.
      */

   It's also possible to use other adaptive filling packages, notably
Kyle E. Jones' Filladapt package(2), which handles things like bulleted
lists nicely.  There's a convenience function `c-setup-filladapt' that
tunes the relevant variables in Filladapt for use in CC Mode.  Call it
from a mode hook, e.g. with something like this in your `.emacs':

     (defun my-c-mode-common-hook ()
       (c-setup-filladapt)
       (filladapt-mode 1))
     (add-hook 'c-mode-common-hook 'my-c-mode-common-hook)

   Normally the comment line prefix inserted for a new line inside a
comment is deduced from other lines in it.  However there's one
situation when there's no clue about how the prefix should look, namely
when a block comment is broken for the first time.  The string in the
style variable `c-block-comment-prefix'(3) is used in that case.  It
defaults to `* ', which makes a comment

     /* Got O(n^2) here, which is a Bad Thing. */

break into

     /* Got O(n^2) here,
      * which is a Bad Thing. */

   Note that it won't work to justify the indentation by putting leading
spaces in the `c-block-comment-prefix' string, since CC Mode still uses
the normal indentation engine to indent the line.  Thus, the right way
to fix the indentation is by setting the `c' syntactic symbol.  It
defaults to `c-lineup-C-comments', which handles the indentation of
most common comment styles, see *Note Indentation Functions::.

   When auto fill mode is enabled, CC Mode can selectively ignore it
depending on the context the line break would occur in, e.g. to never
break a line automatically inside a string literal.  This behavior can
be controlled with the `c-ignore-auto-fill' variable.  It takes a list
of symbols for the different contexts where auto-filling never should
occur:

   * `string' -- Inside a string or character literal.

   * `c' -- Inside a C style block comment.

   * `c++' -- Inside a C++ style line comment.

   * `cpp' -- Inside a preprocessor directive.

   * `code' -- Anywhere else, i.e. in normal code.

   By default, `c-ignore-auto-fill' is set to `'(string cpp code)',
which means that auto-filling only occurs in comments when auto-fill
mode is activated.  In literals, it's often desirable to have explicit
control over newlines.  In preprocessor directives, the necessary `\'
escape character before the newline is not automatically inserted, so
an automatic line break would produce invalid code.  In normal code,
line breaks are normally dictated by some logical structure in the code
rather than the last whitespace character, so automatic line breaks
there will produce poor results in the current implementation.

   The commands that does the actual work follows.

`M-q' (`c-fill-paragraph')
     This is the replacement for `fill-paragraph' in CC Mode buffers.
     It's used to fill multiline string literals and both block and
     line style comments.  In Java buffers, the Javadoc markup words are
     recognized as paragraph starters.  The line oriented Pike autodoc
     markup words are recognized in the same way in Pike mode.

     The function keeps the comment starters and enders of block
     comments as they were before the filling.  This means that a
     comment ender on the same line as the paragraph being filled will
     be filled with the paragraph, and one on a line by itself will
     stay as it is.  The comment starter is handled similarly(4).

`M-j' (`c-indent-new-comment-line')
     This is the replacement for `indent-new-comment-line'.  It breaks
     the line at point and indents the new line like the current one.

     If inside a comment and `comment-multi-line' is non-`nil', the
     indentation and line prefix are preserved.  If inside a comment and
     `comment-multi-line' is `nil', a new comment of the same type is
     started on the next line and indented as appropriate for comments.

`M-x c-context-line-break'
     This is a function that works like `indent-new-comment-line' in
     comments and `newline-and-indent' elsewhere, thus combining those
     two in a way that uses each one in the context it's best suited
     for.  I.e. in comments the comment line prefix and indentation is
     kept for the new line, and in normal code it's indented according
     to context by the indentation engine.

     It's not bound to a key by default, but it's intended to be used
     on the `RET' key.  If you like the behavior of
     `newline-and-indent' on `RET', you might consider switching to
     this function.

   ---------- Footnotes ----------

   (1) `comment-start', `comment-end', `comment-start-skip',
`paragraph-start', `paragraph-separate', `paragraph-ignore-fill-prefix',
`adaptive-fill-mode', `adaptive-fill-regexp', and
`adaptive-fill-first-line-regexp'.

   (2) It's available from `http://www.wonderworks.com/'.  As of
version 2.12, it does however lack a feature that makes it work
suboptimally when `c-comment-prefix-regexp' matches the empty string
(which it does by default).  A patch for that is available from the CC
Mode site.

   (3) In versions before 5.26, this variable was called
`c-comment-continuation-stars'.  As a compatibility measure, CC Mode
still uses the value on that variable if it's set.

   (4) This means that the variables `c-hanging-comment-starter-p' and
`c-hanging-comment-ender-p', which controlled this behavior in earlier
versions of CC Mode, are now obsolete.


File: ccmode,  Node: Commands,  Next: Customizing Indentation,  Prev: Text Filling and Line Breaking,  Up: Top

Commands
********

* Menu:

* Indentation Commands::
* Movement Commands::
* Other Commands::

   See also *Note Text Filling and Line Breaking::, for commands
concerning that bit.


File: ccmode,  Node: Indentation Commands,  Next: Movement Commands,  Up: Commands

Indentation Commands
====================

   The following list of commands re-indent C constructs.  Note that
when you change your coding style, either interactively or through some
other means, your file does _not_ automatically get re-indented.  You
will need to execute one of the following commands to see the effects of
your changes.

   Also, variables like `c-hanging-*' and `c-cleanup-list' only affect
how on-the-fly code is formatted.  Changing the "hanginess" of a brace
and then re-indenting, will not move the brace to a different line.
For this, you're better off getting an external program like GNU
`indent', which will re-arrange brace location, among other things.

   Re-indenting large sections of code can take a long time.  When CC
Mode reindents a region of code, it is essentially equivalent to
hitting `TAB' on every line of the region.  Especially vulnerable is
code generator output(1).

   These commands are useful when indenting code:

`TAB' (`c-indent-command')
     Indents the current line.  The actual behavior is controlled by
     several variables, described below.  See `c-tab-always-indent',
     `c-insert-tab-function', and `indent-tabs-mode'.  With a numeric
     argument, this command rigidly indents the region, preserving the
     relative indentation among the lines.

`M-C-q' (`c-indent-exp')
     Indent an entire balanced brace or parenthesis expression.  Note
     that point must be on the opening brace or parenthesis of the
     expression you want to indent.

`C-c C-q' (`c-indent-defun')
     Indents the entire top-level function or class definition
     encompassing point.  It leaves point unchanged.  This function
     can't be used to re-indent a nested brace construct, such as a
     nested class or function, or a Java method.  The top-level
     construct being re-indented must be complete, i.e. it must have
     both a beginning brace and an ending brace.

`M-C-\' (`indent-region')
     Indents an arbitrary region of code.  This is a standard Emacs
     command, tailored for C code in a CC Mode buffer.  Note that of
     course, point and mark must delineate the region you want to
     indent.

`M-C-h' (`c-mark-function')
     While not strictly an indentation command, this is useful for
     marking the current top-level function or class definition as the
     current region.  As with `c-indent-defun', this command operates on
     top-level constructs, and can't be used to mark say, a Java method.

   These variables are also useful when indenting code:

`c-tab-always-indent'
     This variable controls how `TAB' `c-indent-command' operates.
     When this variable is `t', `TAB' always just indents the current
     line.  When it is `nil', the line is indented only if point is at
     the left margin, or on or before the first non-whitespace
     character on the line, otherwise some whitespace is inserted.  If
     this variable is the symbol `other', then some whitespace is
     inserted only within strings and comments (literals), an inside
     preprocessor directives, but the line is always reindented.

`c-insert-tab-function'
     When "some whitespace" is inserted as described above, what
     actually happens is that the function stored in
     `c-insert-tab-function' is called.  Normally, this just inserts a
     real tab character, or the equivalent number of spaces, depending
     on `indent-tabs-mode'.  Some people, however, set
     `c-insert-tab-function' to `tab-to-t