Re: parser.yy: rearrange to allow more lenient use of music arguments for music functions. (issue4815052)

[mtsolo]

http://codereview.appspot.com/4815052/diff/2001/Documentation/extending/programming-interface.itely
File Documentation/extending/programming-interface.itely (right):

http://codereview.appspot.com/4815052/diff/2001/Documentation/extending/programming-interface.itely#newcode146
Documentation/extending/programming-interface.itely:146:
Can you give a more lilypond examples as you do above (with s 1*0-\fun).
 I think that is very clear, and more examples like that would help
understand this faster.

http://codereview.appspot.com/4815052/diff/2001/lily/parser.yy
File lily/parser.yy (right):

http://codereview.appspot.com/4815052/diff/2001/lily/parser.yy#newcode1598
lily/parser.yy:1598: }
I think this points to a larger issue of the information that enclosing
characters (brackets, parentheses, etc.) carry in LilyPond.  Is there a
way, like in LaTeX with verb, that people can construct their own
begininning and end delimiters to help the parser?  This would not only
be useful here, but in cases like \musicFunction { a \times 2/3 { a b }
c } which in LilyPond would compile the tuplet on two notes.  However,
if we could do \musicFunction ={ a \times 2/3 { a b =} c }, then the
parser could know that ={ and =} are supposed to go into the music
function.

http://codereview.appspot.com/4815052/