2009/7/29 Graham Percival <gra...@percival-music.ca>:
> 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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
