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 and/or emacs (issue4662074)


From: Keith OHara
Subject: Re: Adapt fixcc.py to use Astyle and/or emacs (issue4662074)
Date: Wed, 06 Jul 2011 13:28:55 -0700
User-agent: Opera Mail/11.50 (Win32)

On Wed, 06 Jul 2011 12:55:31 -0700, Graham Percival <address@hidden> wrote:

On Wed, Jul 06, 2011 at 07:04:11PM +0000, address@hidden wrote:
I do think that it's important that the suggestion that
Emacs would not indent GNU code correctly has been withdrawn.

I agree; I'm not quite certain where that suggestion arose,


Probably when I was confused why fixcc(emacs) was messing up unbraced do-while.

I did not suspect that the regex pre-filter would so sophisticated to break the 
; onto its own line, and then later join it back if there was a } before the 
while !

Emacs does need /some/ human help to indent GNU code correctly. Sometimes she 
needs extra parenthesis to understand operator precedence, as explained near 
the end of 
http://www.gnu.org/prep/standards/html_node/Formatting.html#Formatting

On the one hand, it is silly in a monty-pythonesque way to
depend on and run Emacs to indent code where astyle would do.
On the other hand, it is equally silly to suggest that astyle
would be required to indent GNU code after editing with Emacs.

But we're not talking about GNU code.  We're talking about
lilypond code, and lilypond code has never been formatted exactly
the way that emacs does -- otherwise fixcc.py wouldn't exist!


There is no need for an emacs user to run the tool if
1) he remembers the extra things that fixcc does "foo (a, b)"
2) he can control emacs' indenter so that there are not /too/ many
distracting whitespace changes^H^Hcorrections in his patches
   long_var = first_term
-             + second_term;
+    + second_term;


On the other hand,
The rest of us have already learned to control out auto-indenters,
so we will probably not cry if you ask us to install emacs as well.

I am drifting toward the belief that we will face less confusion,
under practical circumstances with human error, if we just adopt
fixcc(emacs).   So, please critically review my gutting of fixcc!




reply via email to

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