Small corrections to the scheme reformatting patch.

Small corrections to the scheme reformatting patch.

[marc, 2013-06-07 10:04:57]

include Keith's suggestions

[dak, 2013-06-09 08:35:27]

https://codereview.appspot.com/9964049/diff/2001/scm/define-context-propertie...
File scm/define-context-properties.scm (right):

https://codereview.appspot.com/9964049/diff/2001/scm/define-context-propertie...
scm/define-context-properties.scm:524: @}
This won't work.  You clean up after a problem of fixscm (which got confused),
but you don't fix the problem.  The next time fixscm is getting run, this will
get wrecked just like it was last time round.

And if our policy is going to be "don't run fixscm on this file ever again",
then we can save ourselved the hassle of running it even once.

[marc, 2013-06-09 12:11:22]

https://codereview.appspot.com/9964049/diff/2001/scm/define-context-propertie...
File scm/define-context-properties.scm (right):

https://codereview.appspot.com/9964049/diff/2001/scm/define-context-propertie...
scm/define-context-properties.scm:524: @}
On 2013/06/09 08:35:27, dak wrote:
> This won't work. 

It did work. If you run fixscm.sh on the changed file,
it clearly says:

(No changes need to be saved)

at the end of the terminal output.

But if there is something that may be improved (either on the
indentaion script or the source file), then I need some more
information rather than "this won't work" ;-)

[dak, 2013-06-09 12:48:14]

On 2013/06/09 12:11:22, marc wrote:
>
https://codereview.appspot.com/9964049/diff/2001/scm/define-context-propertie...
> File scm/define-context-properties.scm (right):
> 
>
https://codereview.appspot.com/9964049/diff/2001/scm/define-context-propertie...
> scm/define-context-properties.scm:524: @}
> On 2013/06/09 08:35:27, dak wrote:
> > This won't work. 
> 
> It did work. If you run fixscm.sh on the changed file,
> it clearly says:
> 
> (No changes need to be saved)
> 
> at the end of the terminal output.
> 
> But if there is something that may be improved (either on the
> indentaion script or the source file), then I need some more
> information rather than "this won't work" ;-)

You should base your work likely on
<URL:http://codereview.appspot.com/10078046>.  In that patch, I worked on the
source files until
  (setq open-paren-in-column-0-is-defun-start nil)
would no longer generate different output when calling fixscm scm/*.scm

It would be more reliable to repeat that comparison with different indentation
settings (to make sure that one did not overlook already properly indented
material that did not get reindented because mistakenly assumed to be inside of
a string), but since this was starting from the state before running fixscm for
the first time, it's likely pretty complete.

[dak, 2013-06-10 08:35:11]

https://codereview.appspot.com/9964049/diff/2001/scm/define-context-propertie...
File scm/define-context-properties.scm (right):

https://codereview.appspot.com/9964049/diff/2001/scm/define-context-propertie...
scm/define-context-properties.scm:524: @}
On 2013/06/09 12:11:23, marc wrote:
> On 2013/06/09 08:35:27, dak wrote:
> > This won't work. 
> 
> It did work.

Well, I prefer Emacs not messing with the inside of strings over preformatting
the strings such that the mess is looking better (and the braces did not line up
anyway).  My preparatory patch for issue 3404 looks like it caught this one
properly.

https://codereview.appspot.com/9964049/diff/2001/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):

https://codereview.appspot.com/9964049/diff/2001/scm/define-grob-properties.s...
scm/define-grob-properties.scm:973: (centered on the note head), @code{1.0}
means centered on the stem.
Better to fix the (@code{1}=>up line above.  Done.

https://codereview.appspot.com/9964049/diff/2001/scm/define-markup-commands.scm
File scm/define-markup-commands.scm (right):

https://codereview.appspot.com/9964049/diff/2001/scm/define-markup-commands.s...
scm/define-markup-commands.scm:3039: (cond ;; ((= num 6) (interval-widen
number-interval (* mag 0.5)))
These outcommented passages still need to get committed in the style shown here.

But I lean towards finishing this properly rather than letting it stay around in
half-outcommented state.  If anybody wants to look at the old state, that's what
git is for.  And working with git is made harder, not easier, by juggling around
with uncommented code of unknown age and providence.

The current state was established with
commit 7b716659ab09847e998528c2afdde6aa34c7d24c
Author: Reinhold Kainhofer <reinhold@kainhofer.com>
Date:   Tue Jun 10 19:44:47 2008 +0200

    figured bass: Implement backslashed figures (raised 6th steps)
[...]
    For some numbers I also enlarge the slash in X directions to make it
    more visible (my hand-engraved scores use an even larger slash than
    lilypond, anyway). I also move the slash up/down for some numbers
    to make it more visible.
    
    Also use the real Y extents of the slash rather than the whole interval
    for the number. As we shift the slash for some numbers, otherwise
    it would make the whole digit larger and shift it down for no apparent
    visual reason.

https://codereview.appspot.com/9964049/diff/2001/scm/define-markup-commands.s...
scm/define-markup-commands.scm:3071: ;; backward slashes might use slope and
point in the other direction!
Those ;; however make sense.

https://codereview.appspot.com/9964049/diff/2001/scm/time-signature-settings.scm
File scm/time-signature-settings.scm (right):

https://codereview.appspot.com/9964049/diff/2001/scm/time-signature-settings....
scm/time-signature-settings.scm:316: (make-left-column-markup
And this also makes sense.