Applies scheme indentation according to the GNU guidelines

Applies scheme indentation according to the GNU guidelines

This is the result of
scripts/auxiliar/fixscm.sh scm/*
with some manual tweaking in clip-region.scm where ';:'
instead of ';;' was used as a comment sign.

[janek, 2012-11-10 13:59:23]

I've looked a bit at one random file.  Looks mostly good to me.

http://codereview.appspot.com/6814080/diff/1/scm/define-music-display-methods...
File scm/define-music-display-methods.scm (right):

http://codereview.appspot.com/6814080/diff/1/scm/define-music-display-methods...
scm/define-music-display-methods.scm:111: remember)
Isn't this indent too big?

[dak, 2012-11-11 08:40:09]

Marc Hohl <marc@hohlart.de> writes:

> Am 10.11.2012 14:59, schrieb janek.lilypond@gmail.com:
>> I've looked a bit at one random file.  Looks mostly good to me.
>>
>>
>>
http://codereview.appspot.com/6814080/diff/1/scm/define-music-display-methods...
>>
>> File scm/define-music-display-methods.scm (right):
>>
>>
http://codereview.appspot.com/6814080/diff/1/scm/define-music-display-methods...
>>
>> scm/define-music-display-methods.scm:111: remember)
>> Isn't this indent too big?
> No, it aligns to the first argument of
>
> (define*-public (duration->lily-string ...)
>
> and this follows the 'do what emacs does' guideline ;-)

If Emacs does something different for define*-public and define by oversight or
omission, then the "do what Emacs does" guideline should not be interpreted
literally.

So as long as Emacs does not produce consistent results, either the input needs
to get manually arranged in a manner that makes Emacs produce reasonable
results, or we need to make Emacs produce the right results in our scripts
(and/or the interactive Emacs settings) by making all define-like commands known
to Emacs' indentation engine.  While this is not the case, a blanket
reformatting of our entire source code according to defective rules should not
be done.

[Graham Percival, 2012-11-11 12:45:31]

Some people (notably Jan) were quite vocal about wanting to use "whatever emacs
does" literally, regardless of bugs.  I support this view; the important thing
is consistent indentation.

However, I don't see any fixscm.sh in this patch.  Also, I'd like to get the
fixes to clip-region added, regardless of any further debate about reproducing
emacs bugs or not.  Could you push a fix to the comments in clip-region.scm,
then put a patch that adds fixscm.sh on rietveld?

[Graham Percival, 2012-11-11 22:32:17]

On Sun, Nov 11, 2012 at 02:22:30PM +0100, Marc Hohl wrote:
> Am 11.11.2012 13:45, schrieb graham@percival-music.ca:
> >Some people (notably Jan) were quite vocal about wanting to use
> >"whatever emacs does" literally, regardless of bugs.  I support this
> >view; the important thing is consistent indentation.
> >
> >However, I don't see any fixscm.sh in this patch.
> I don't know whether I understand you correctly.
> fixscm.sh is in scripts/auxiliar/ already, how is it supposed to be
> included in a patch again?

Sorry, I was looking at an old repository that hadn't been
updated.  Please ignore.

> >  Also, I'd like to get
> >the fixes to clip-region added, regardless of any further debate about
> >reproducing emacs bugs or not.  Could you push a fix to the comments in
> >clip-region.scm,
> Shall I push the changes ';:'->';;' directly to staging, or open a new issue
> for that?

Please push the ;: -> ;; change directly to staging.

- Graham

[marc, 2012-11-12 20:50:52]

Looking a little closer through the bunch of lines,
this is far from being pushed.

(1) There are single ';' comments spread throughout
    various scheme files, and emacs doesn't like them.
    The best way to eliminate them is to manually replace
    them (I don't trust a script here) before running
    fixscm.sh

(2) Lists seem to be formatted as if the first entry were
    a function; is there a way to convince emacs to
    do this differently?

http://codereview.appspot.com/6814080/diff/1/scm/chord-entry.scm
File scm/chord-entry.scm (left):

http://codereview.appspot.com/6814080/diff/1/scm/chord-entry.scm#oldcode18
scm/chord-entry.scm:18: ; for define-safe-public when byte-compiling using Guile
V2
there are *a lot* of comments starting with just
a single ';' instead of ';;'.

I think a separate commit for just this issue should
be created? This means a lot of manual search&replace :-(

http://codereview.appspot.com/6814080/diff/1/scm/define-event-classes.scm
File scm/define-event-classes.scm (right):

http://codereview.appspot.com/6814080/diff/1/scm/define-event-classes.scm#new...
scm/define-event-classes.scm:29: arpeggio-event breathing-event extender-event
span-event
This is just ugly; how can I prevent emacs from doing this?

http://codereview.appspot.com/6814080/diff/1/scm/define-grob-interfaces.scm
File scm/define-grob-interfaces.scm (left):

http://codereview.appspot.com/6814080/diff/1/scm/define-grob-interfaces.scm#o...
scm/define-grob-interfaces.scm:114: thickness))
This indentation is not correct IMHO.
How can emacs format a list accordingly?

http://codereview.appspot.com/6814080/diff/1/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):

http://codereview.appspot.com/6814080/diff/1/scm/define-grob-properties.scm#n...
scm/define-grob-properties.scm:34: ;;
well, there is probably no easy way to convince
emacs not to indent this, but it looks not too bad, either...

http://codereview.appspot.com/6814080/diff/1/scm/define-music-types.scm
File scm/define-music-types.scm (left):

http://codereview.appspot.com/6814080/diff/1/scm/define-music-types.scm#oldco...
scm/define-music-types.scm:19: ; for define-safe-public when byte-compiling
using Guile V2
... and some more spurious single ';' comments
malformatted.