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
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
