On Thu, Jun 30, 2011 at 12:04:11AM -0700, Keith OHara wrote: > On Wed, 29 Jun 2011 21:05:51 -0700, Carl Sorensen <c_soren...@byu.edu> wrote: > > >Do you have the ability to easily test a change that doesn't pad a > >parenthesis if it's following the same character, ie. (( won't get an extra > >space? > > It turns out to be very easy to modify astyle so as to skip the padding > between (( and )[ . > There was already a list of exceptions to avoid padding in cases like ); . > > Presumably, other users depend on astyle working as it does with the current > options. The maintainer recently surveyed users about which options they use. > > We could use a regexp pre-filter to add space where gnu-style wants it, and > use that as a model to support the request for a new option in astyle.
Ok, but we'd still need to remove the space in ") )" or ") ]" in post-processing, right? And are we ok without having a facility to skip over comments and strings? If we can get acceptable code with astyle 2.02, using any combination of pre- and/or post-filtering, then I think we should go for it. If astyle 2.02 messes up something that we care about, and can't fix in pre- or post-filtering, then I think we should adopt fixcc.py for the immediate future. We could potentially plan on switching to astyle in a few months, but I'd still want to run fixcc.py on the entire repo. I don't want to leave this hanging yet again. It's great to work with the astyle project with a view towards using astyle 2.03 with no filtering at all, but I'd like to end this discussion with an official automatic formatter in place. As I've said before, I rarely look at the C++ code in lilypond. In other C++ projects that I *do* work on (marsyas, vivi, artifastring, rosegarden), I'm not at all fussy with style. If anybody has difficulty with git but wants to see what we're talking about, they can get fix-astyle-fiddle.py here: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=blob;f=fix-astyle-fiddle.py;h=427c8ab6270cfbd8315e3059c7a6eb79a90e4ef2;hb=091a7e73d5744bb86a8f53ed731c5ca52eb26b2a (click on the filename to download) I'm fairly certain that this file is *not* what Keith has in mind, but at least it should help you get up to speed on the issues that we're talking about. (anybody is welcome to push changes to that script; I'm not fussy about only me touching stuff in dev/gperciva-astyle) Cheers, - Graham _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel