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-', 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 ) 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 key(1) will consume all preceding whitespace, including newlines and tabs. This can really cut down on the number of 's you have to type if, for example you made a mistake on the preceding line. By default, when you hit the key CC Mode runs the command `c-electric-backspace', which deletes text in the backwards direction. When deleting a single character, or when 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 key depends on the flavor of Emacs you are using. By default in XEmacs 20.3 and beyond, the key is bound to `c-electric-delete'. You control the direction that the 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 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 and 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 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-tab-stop' so as to get hard tab stops when indenting. `indent-tabs-mode' This is a standard Emacs variable that controls how line indentation is composed. When this variable is non-`nil', then tabs can be used in a line's indentation, otherwise only spaces can be used. `c-progress-interval' When indenting large regions of code, this variable controls how often a progress message is displayed. Set this variable to `nil' to inhibit the progress messages, or set it to an integer which is the interval in seconds that progress messages are displayed. ---------- Footnotes ---------- (1) In particular, I have had people complain about the speed with which `lex(1)' output is re-indented. Lex, yacc, and other code generators usually output some pretty perversely formatted code. Re-indenting such code will be slow.