Re: tabs vs. spaces in source code

[Neil Puttock]

2009/7/29 Graham Percival <address@hidden>:

> Let's tackle the cc files first.  I tried running it on everything
> lily/*.cc, and ended up with a 126K diff.
>
> 1) many changes were simply moving */ to the left by 1 char.
>   That's fine.

I've amended these myself a few times, but it's just occurred to me
the extra space could be the result of applying the `two spaces after
a full stop' rule (even if it doesn't make as much sense in .cc
files).

> 2) *lots* of changes were like this:
> -----
> @@ -46,7 +46,7 @@ Align_interface::calc_positioning_done (SCM smob)
>   TODO: This belongs to the old two-pass spacing. Delete me.
>  */
>  MAKE_SCHEME_CALLBACK (Align_interface, stretch_after_break, 1)
> -SCM
> +  SCM
>  Align_interface::stretch_after_break (SCM grob)
>  {
>   Grob *me = unsmob_grob (grob);
> -----
>
> This also looks fine to me, although I admit that I'm not certain
> whether SCM is a macro or what.

It is a macro, but as the return type for the method
stretch_after_break (), it shouldn't be indented.  It seems your
version of emacs is misinterpreting the `SCM' line as a continuation
of the MAKE_SCHEME_CALLBACK macro, since it's missing a semicolon
after the closing parenthesis.

My installed emacs must have a slightly different indentation
algorithm, since it only produces similarly incorrect results for two
cases in global-context-scheme.cc after LY_ASSERT_TYPE macros.

> 6)  If we want to use this, the patch needs to be examined
> carefully.  There aren't many problems, but we definitely
> shouldn't apply it blindly.  (we'd have lost that good comment
> otherwise!)

I think it would be better to use fixcc.py for the C++ files, since it
nitpicks the code more thoroughly.

Regards,
Neil