ccmode: Statement Block Symbols

 
 10.2.12 Statement Block Symbols
 -------------------------------
 
 There are a few occasions where a statement block might be used inside
 an expression.  One is in C or C++ code using the gcc extension for
 this, e.g.:
 
       1: int res = ({
       2:         int y = foo (); int z;
       3:         if (y > 0) z = y; else z = - y;
       4:         z;
       5:     });
 
    Lines 2 and 5 get the ‘inexpr-statement’ syntax, besides the symbols
 they’d get in a normal block.  Therefore, the indentation put on
 ‘inexpr-statement’ is added to the normal statement block indentation.
 An ‘inexpr-statement’ syntactic element doesn’t contain an anchor
 position.
 
    In Pike code, there are a few other situations where blocks occur
 inside statements, as illustrated here:
 
       1: array itgob()
       2: {
       3:     string s = map (backtrace()[-2][3..],
       4:                     lambda
       5:                         (mixed arg)
       6:                     {
       7:                         return sprintf ("%t", arg);
       8:                     }) * ", " + "\n";
       9:     return catch {
      10:             write (s + "\n");
      11:         };
      12: }
 
    Lines 4 through 8 contain a lambda function, which CC Mode recognizes
 by the ‘lambda’ keyword.  If the function argument list is put on a line
 of its own, as in line 5, it gets the ‘lambda-intro-cont’ syntax.  The
 function body is handled as an inline method body, with the addition of
 the ‘inlambda’ syntactic symbol.  This means that line 6 gets ‘inlambda’
 and ‘inline-open’, and line 8 gets ‘inline-close’(1).
 
    On line 9, ‘catch’ is a special function taking a statement block as
 its argument.  The block is handled as an in-expression statement with
 the ‘inexpr-statement’ syntax, just like the gcc extended C example
 above.  The other similar special function, ‘gauge’, is handled like
 this too.
 
    ---------- Footnotes ----------
 
    (1) You might wonder why it doesn’t get ‘inlambda’ too.  It’s because
 the closing brace is relative to the opening brace, which stands on its
 own line in this example.  If the opening brace was hanging on the
 previous line, then the closing brace would get the ‘inlambda’ syntax
 too to be indented correctly.