On 6/29/11 6:01 PM, "Keith OHara" <k-ohara5...@oco.net> wrote:
> Graham Percival <graham <at> percival-music.ca> writes:
>
>> At the moment I'm leaning towards using astyle+postprocessing.
>>
>
> By coincidence, I just finished looking over astyle alone.
>
> The options you first proposed aren't enough for me, because I can't remember
> how to gnu-space things like
> me->origin ()->warn (_f ("~s", me->prob ()));
>
> so I just looked at, including `make check`, the results of:
>
> astyle --style=gnu --indent-cases --indent=spaces=2 \
> --max-instatement-indent=60 \
> --align-pointer=name --pad-oper \
> --unpad-paren --pad-paren-out \
> --keep-one-line-blocks --quiet $*
>
> This pads more than just function calls -- padding that can be helpful
> if (line_
> - && ((d == LEFT && !line_->get_bound (LEFT))
> - || (end && d == RIGHT && !line_->get_bound (RIGHT))))
> + && ( (d == LEFT && !line_->get_bound (LEFT))
> + || (end && d == RIGHT && !line_->get_bound (RIGHT))))
I am ambivalent about the padding above.
>
> or maybe annoying
> - if (Stem::get_beam ((*stems_)[i]))
> + if (Stem::get_beam ( (*stems_) [i]))
>
I very much dislike the padding above here. Both the space before (*stems)
and the space before [i].
> When the parentheses are empty, either "foo ()" or "foo()" is left unchanged.
>
> Astyle leaves a lot of other spacing unchanged. For example the human has to
> choose which side of the linebreak should have the operator :
> variable =
> one + /* bad style, but easy to catch because it is not gnu-specific
> */
> two;
>
> I submitted a request to indent broken expressions by at least one level after
> the first line (and implemented the change in my copy).
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?
And is there an option to avoid padding [?
Thanks,
Carl
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
