On 2011/07/04 09:28:26, janneke_gnu.org wrote:
The GNU standards are implemented by Emacs,
Well, it looks like the problems with fixcc.py were caused by regexps, not emacs. Also, I tried to make the output of the modified fixcc+asytle pass unchanged through emacs, but the very many cases of line-broken asssignments will be different. long_variable_name = first_term + second_term; // emacs long_variable_name = first_term + second_term; // astyle Emacs users will forget to run fixcc (because they are lazy heathens, as all vi users know :-) causing distracting whitespace changes in the diffs. So *if* we can add back regexps to fixcc.py that do what neither emacs nor programmers do automatically: pad parentheses me->origin (); unpad parenthesis-groups if ((a & mask) == (d & mask)) pad operators array[i + 1] without breaking other things, then we could go back to call emacs for the indenting. Then hopefully the script would commute with emacs fixcc.py (code) == emacs ( fixcc.py (code)) Patches welcome. But until that is done, my proposal remains this shorter prefilter+astyle. http://codereview.appspot.com/4662074/diff/4031/scripts/auxiliar/fixcc.py File scripts/auxiliar/fixcc.py (left): http://codereview.appspot.com/4662074/diff/4031/scripts/auxiliar/fixcc.py#oldcode148 scripts/auxiliar/fixcc.py:148: ('((if|while)\s+\(([^\)]|\([^\)]*\))*\))\s*;', '\\1\n;'), This is what was line-breaking the semicolon on an unbraced do-while! do something; while (relevant) ; So I was wrong to blame emacs for this one when I said
You'll notice that some of the gnu coding standards you linked to, like braces on do-while, are specifically designed to defend against emacs'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#newcode64 scripts/auxiliar/fixcc.py:64: # trailing operator, but don't un-trail assignment operators or close angle-braces > Looking through the existing code, line-broken assignments /do/ get the '=' on the second line long_name = long_initializer; so I could restore that. http://codereview.appspot.com/4662074/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel