GOP-PROP 3: C++ formatting (update)

[Graham Percival]

This is an update, rather than a "probable decision".  I don't
think we're close enough to have a real proposal.

http://lilypond.org/~graham/gop/gop_3.html

At the moment I'm leaning towards using astyle+postprocessing.
The script in question is here:
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=fix-astyle-fiddle.py;h=3bdffd9e8016b1d7fcdbe5cf5c77aecc09763d86;hb=refs/heads/dev/gperciva-astyle

To test it yourself (if you're not familiar with git branches):

1. download, compile, and install astyle 2.02:
http://astyle.sourceforge.net/
NOTE: astyle 2.02 is quite new (May 2011).  It's not in your
package manager.

2. download fix-astyle-fiddle.py
(it "fiddles" with the output of astyle, to fix stuff)

3. run it on your favorite .hh or .cc file:
  python fiddle-astyle.py lily/percival-engraver.cc

You could run it against everything by running
fix-astyle-all.sh
http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=fix-astyle-all.sh;h=c5bf12959acac6ba8438551112280b3b8147e2b3;hb=refs/heads/dev/gperciva-astyle


Suggestions are welcome (particularly for regex in python, because
I don't think that this is the right place for map()), as are
patches to improve the output.

Most welcome of all would be a voiciferous objection to astyle.
Or rather -- if you're going to complain later on, please do it
sooner instead of later.  I don't really know how much effort to
put into fix-astyle-fiddle.py.  If somebody has a great reason why
we shouldn't use it (regardless of whatever postprocessing we
have), then any effort spent on the postprocessing will be
wasted.


I'm hoping to have a firm proposal on Friday or Saturday, but
whenever it happens, we'll have a full week for review and second
thoughts.

Cheers,
- Graham