lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)


From: k-ohara5a5a
Subject: Re: Adapt fixcc.py to use Astyle instead of emacs (issue4662074)
Date: Mon, 04 Jul 2011 03:33:19 +0000

I really, really, wish Astyle had a fully gnu-compliant mode out of the
box.
I went through the regexp's again and think this is good to go.

I'll push a commit showing this run over the whole repository to
<http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=shortlog;h=refs/heads/dev/gperciva-astyle-keith>



http://codereview.appspot.com/4662074/diff/4031/lily/align-interface.cc
File lily/align-interface.cc (right):

http://codereview.appspot.com/4662074/diff/4031/lily/align-interface.cc#newcode375
lily/align-interface.cc:375: "stacking-dir ");
The prefilter in fixcc.py doesn't like the "dangling )"

http://codereview.appspot.com/4662074/diff/4031/lily/audio-item.cc
File lily/audio-item.cc (right):

http://codereview.appspot.com/4662074/diff/4031/lily/audio-item.cc#newcode43
lily/audio-item.cc:43: channel_ (0)
The indenter in emacs un-indents the member initializers, whether we
move the ','  or not, but the names remain aligned

http://codereview.appspot.com/4662074/diff/4031/lily/beam-quanting.cc
File lily/beam-quanting.cc (right):

http://codereview.appspot.com/4662074/diff/4031/lily/beam-quanting.cc#newcode474
lily/beam-quanting.cc:474: std::priority_queue < Beam_configuration *,
std::vector<Beam_configuration *>,
If the template is broken into two lines, astyle does the angle braces
wrongly

http://codereview.appspot.com/4662074/diff/4031/lily/beam.cc
File lily/beam.cc (right):

http://codereview.appspot.com/4662074/diff/4031/lily/beam.cc#newcode70
lily/beam.cc:70: max_connect_ = 1000; // infinity
prefilter in fixcc.py collapses spaces

http://codereview.appspot.com/4662074/diff/4031/lily/context.cc
File lily/context.cc (right):

http://codereview.appspot.com/4662074/diff/4031/lily/context.cc#newcode283
lily/context.cc:283: add_listener (GET_LISTENER
(new_context->create_context_from_event),
astyle does not (yet) indent line-broken statements if there is no
appropriate operator to align to

http://codereview.appspot.com/4662074/diff/4031/lily/context.cc#newcode330
lily/context.cc:330: accepts);
we can set the limit on how far astyle will indent to align with
parentheses; I put 60 columns as the maximum

http://codereview.appspot.com/4662074/diff/4031/lily/general-scheme.cc
File lily/general-scheme.cc (right):

http://codereview.appspot.com/4662074/diff/4031/lily/general-scheme.cc#newcode55
lily/general-scheme.cc:55: tail = SCM_CDRLOC (*tail);
this is why I need the prefilter in fixcc.py

http://codereview.appspot.com/4662074/diff/4031/lily/general-scheme.cc#newcode217
lily/general-scheme.cc:217: + default_value_string + "'.");
the prefilter in fixcc.py moves the + s

http://codereview.appspot.com/4662074/diff/4031/scripts/auxiliar/fixcc.py
File scripts/auxiliar/fixcc.py (right):

http://codereview.appspot.com/4662074/diff/4031/scripts/auxiliar/fixcc.py#newcode120
scripts/auxiliar/fixcc.py:120: \#[ \t]*define[
\t]+([^\n]*\\\n)*[^\n]*))''',
I made a pattern to skip over defines, as it skips over comments, and
leave them un-touched.  The old method of un-doing the damage prefilter
did to #defines, made me nervous.

http://codereview.appspot.com/4662074/diff/4031/test.c
File test.c (right):

http://codereview.appspot.com/4662074/diff/4031/test.c#newcode1
test.c:1: #       include       < foo(bar(baz >
compare to Patch set 2 to see the effect of
fixcc.py with astyle

http://codereview.appspot.com/4662074/diff/4031/testfile_fixcc_emacs.c
File testfile_fixcc_emacs.c (right):

http://codereview.appspot.com/4662074/diff/4031/testfile_fixcc_emacs.c#newcode1
testfile_fixcc_emacs.c:1: /* testfile from fixcc.py, as *output* from
fixcc.py using emacs */
The output of the old, more-picky fixcc+emacs is left unchanged by
fixcc+astyle. (No diff set 2--3)

http://codereview.appspot.com/4662074/diff/4031/testfile_in.c
File testfile_in.c (right):

http://codereview.appspot.com/4662074/diff/4031/testfile_in.c#newcode39
testfile_in.c:39: !OK  OK
These comments were messed-up on input, and they remain so on output.  I
just tested with the testfile; I didn't write it.

http://codereview.appspot.com/4662074/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]