Reformat some files to let emacs do its work correctly.

Reformat some files to let emacs do its work correctly.

[Keith, 2013-06-04 06:33:11]

LGTM
It makes sense to let humans look at the hand-made changes, and then just run
fixscm.sh and let

https://codereview.appspot.com/9863047/diff/1/scm/define-grob-interfaces.scm
File scm/define-grob-interfaces.scm (right):

https://codereview.appspot.com/9863047/diff/1/scm/define-grob-interfaces.scm#...
scm/define-grob-interfaces.scm:76: '(delta-position
Lists that fit all on one line are good on one line.
These changes are okay, but I suggest reversing them so the code history is
easier to follow.

[Keith, 2013-06-04 06:33:19]

LGTM
It makes sense to let humans look at the hand-made changes, and then just run
fixscm.sh and let `make check

[Keith, 2013-06-04 06:33:20]

LGTM
It makes sense to let humans look at the hand-made changes, and then just run
fixscm.sh and let `make check

[Keith, 2013-06-04 06:33:43]

LGTM
It makes sense to let humans look at the hand-made changes, and then just run
fixscm.sh and let `make check` test that.

[marc, 2013-06-04 08:56:59]

On 2013/06/04 06:33:11, Keith wrote:
> LGTM
> It makes sense to let humans look at the hand-made changes, and then just run
> fixscm.sh and let `make check` test that.

Ok. Since fixscm.sh was applied once without breaking the build process,
it is rather unlikely to get unwanted surprises ...

> https://codereview.appspot.com/9863047/diff/1/scm/define-grob-interfaces.scm
> File scm/define-grob-interfaces.scm (right):
> 
>
https://codereview.appspot.com/9863047/diff/1/scm/define-grob-interfaces.scm#...
> scm/define-grob-interfaces.scm:76: '(delta-position
> Lists that fit all on one line are good on one line.
> These changes are okay, but I suggest reversing them so the code history is
> easier to follow.

I for myself like the new formatting; it's closer to the
list of properties at the end of the c++ engraver files.

[dak, 2013-06-06 09:44:49]

https://codereview.appspot.com/9863047/diff/1/scm/define-context-properties.scm
File scm/define-context-properties.scm (right):

https://codereview.appspot.com/9863047/diff/1/scm/define-context-properties.s...
scm/define-context-properties.scm:325: (glissandoMap ,list? "A map in the form
of
_Every_ change in this file is _inside_ of strings, not exactly increasing their
usefulness as documentation strings.  I really don't understand why not even the
author of large automated changes apparently can be bothered to scan once
through the diff before committing.

Obviously, the formatter is thrown off-track.  Probably it should set
open-paren-in-column-0-is-defun-start to nil, cf.
<URL:http://www.gnu.org/software/emacs/manual/html_node/emacs/Left-Margin-Paren.html>.
 Alternatively, fix the strings in question that confuse the formatter.  And
then revert and reformat this file.

[dak, 2013-06-06 09:50:36]

https://codereview.appspot.com/9863047/diff/1/scm/define-context-properties.scm
File scm/define-context-properties.scm (right):

https://codereview.appspot.com/9863047/diff/1/scm/define-context-properties.s...
scm/define-context-properties.scm:325: (glissandoMap ,list? "A map in the form
of
On 2013/06/06 09:44:49, dak wrote:
> _Every_ change in this file is _inside_ of strings, not exactly increasing
their
> usefulness as documentation strings.  I really don't understand why not even
the
> author of large automated changes apparently can be bothered to scan once
> through the diff before committing.
> 
> Obviously, the formatter is thrown off-track.  Probably it should set
> open-paren-in-column-0-is-defun-start to nil, cf.
>
<URL:http://www.gnu.org/software/emacs/manual/html_node/emacs/Left-Margin-Paren.html>.
>  Alternatively, fix the strings in question that confuse the formatter.  And
> then revert and reformat this file.

The committed diff does not actually correspond to what this patch shows (why?),
but it still meddles with the inside of strings:
@@ -516,9 +516,9 @@ voices is preserved.
 @example
 @{
   r1 r1*3 R1*3
-  \\set Score.skipBars= ##t
-  r1*3 R1*3
-@}
+     \\set Score.skipBars= ##t
+     r1*3 R1*3
+     @}
 @end example")

[dak, 2013-06-06 09:57:05]

https://codereview.appspot.com/9863047/diff/1/scm/define-context-properties.scm
File scm/define-context-properties.scm (right):

https://codereview.appspot.com/9863047/diff/1/scm/define-context-properties.s...
scm/define-context-properties.scm:325: (glissandoMap ,list? "A map in the form
of
On 2013/06/06 09:44:49, dak wrote:
> _Every_ change in this file is _inside_ of strings, not exactly increasing
their
> usefulness as documentation strings.

Ok, apparently I mixed up the purpose of this patch (which exactly was _not_ an
automated patch but rather reformatted the strings in order to keep them from
having a bad effect on the formatter).  Sorry for that.  Still, the automated
commit following after this patch still reformats inside of strings, so the
preparation this patch was supposed to be doing would appear to have been
incomplete.

[marc, 2013-06-07 06:04:29]

On 2013/06/06 09:57:05, dak wrote:
>
https://codereview.appspot.com/9863047/diff/1/scm/define-context-properties.scm
> File scm/define-context-properties.scm (right):
> 
>
https://codereview.appspot.com/9863047/diff/1/scm/define-context-properties.s...
> scm/define-context-properties.scm:325: (glissandoMap ,list? "A map in the form
> of
> On 2013/06/06 09:44:49, dak wrote:
> > _Every_ change in this file is _inside_ of strings, not exactly increasing
> their
> > usefulness as documentation strings.
> 
> Ok, apparently I mixed up the purpose of this patch (which exactly was _not_
an
> automated patch but rather reformatted the strings in order to keep them from
> having a bad effect on the formatter).  Sorry for that.

Never mind.


>  Still, the automated
> commit following after this patch still reformats inside of strings, so the
> preparation this patch was supposed to be doing would appear to have been
> incomplete.

I underestimated the time needed for this patch; I think I spent three
hours in front of my computer editing files, applying fixscm, looking for
places where it goes havoc, reverting the changes, editing again etc. etc.
The patch is rather big (in fact too big to be handled by patchy), so
having overlooked three instances seems not to be that bad, isn't it?

;-)

I think I'll draw a patch that corrects the minor faults; ideally, running
fixscm again should lead in no changes at all.

[pkx166h, 2013-06-07 12:53:01]

On 7 June 2013 11:07, Marc Hohl <marc@hohlart.de> wrote:

> Am 07.06.2013 09:07, schrieb Keith OHara:
>
>> On Thu, 06 Jun 2013 23:04:29 -0700, <marc@hohlart.de> wrote:
>>
>>  I think I'll draw a patch that corrects the minor faults; ideally,
>>> running
>>> fixscm again should lead in no changes at all.
>>>
>>>
>> That makes good sense.
>>
>> It is hard to spot unwanted changes among the good changes from running
>> the script.
>>
>>
>> time-signature-settings.scm, maybe some newlines
>>
>> @@ -312,24 +312,24 @@ a fresh copy of the list-head is made."
>>            (den (car revargs))
>>            (nums (reverse (cdr revargs))))
>>       (make-override-markup '(baseline-skip . 0)
>> -      (make-number-markup
>> -        (make-left-column-markup (list
>> -          (make-center-column-markup (list
>> -            (make-line-markup (insert-markups nums "+"))
>> -            den))))))))
>> +                          (make-number-markup
>> +                           (make-left-column-markup (list
>> +
>> (make-center-column-markup (list
>> +
>> (make-line-markup (insert-markups nums "+"))
>> +
>> den))))))))
>>
>
> done.
>
>>
>> define-markup-commands.scm, maybe some ;;
>>
>> 3037 (define-public (horizontal-slash-interval num forward
>> number-interval mag)
>> 3038   (if forward
>> 3039       (cond ;((= num 6) (interval-widen number-interval (* mag 0.5)))
>> 3040                                         ;((= num 5) (interval-widen
>> number-interval (* mag 0.5)))
>> ...
>>
>>  done. Thanks!
>
> BTW, I raised a new issue for this:
>
>
http://code.google.com/p/**lilypond/issues/detail?id=3404<http://code.google....
>
> and uploaded a patch:
>
>
http://codereview.appspot.com/**9964049<http://codereview.appspot.com/9964049>
>
> Regards,
>
> Marc
>
>
>
>
>>
>
> ______________________________**_________________
> lilypond-devel mailing list
> lilypond-devel@gnu.org
>
https://lists.gnu.org/mailman/**listinfo/lilypond-devel<https://lists.gnu.org...
>


For some reason it wasn't being picked up by Patchy, so I had to
'turn-it-off-and-turn-it-on-again' so that Patch-New was detected for
testing.

In case you wondered.

james