Reviewers: ,
Message:
I should point out that I consider this a merge candidate. AFAICT, it
passes the regtests.
Description:
parser.yy: rearrange to allow more lenient use of music arguments for
music functions.
This change may be somewhat contentious: it removes a lot of
opportunities for syntax errors by allowing a lot of music functions
to work that did not do so previously.
For one thing, you can use a ly:music? style signature as often as you
want to in all music functions. There are some cases where it will
only be accepted in "closed form", namely as a music identifier or a
music expression enclosed in { ... } or << ... >>. Those cases are
before a post-event not belonging to the music argument, or a duration
argument.
Music functions can be used in a number of places with different
semantics, not necessarily the cleanest thing. When they are used as
post-events and have a music argument last, they will actually try
getting a post-event as that music argument. What is new (and
probably less than fabulous) that they will instead accept a closed
form music expression.
However, when such a function is used as a primary music event, its
last argument will be a regular music expression anyway. So it is not
like this argument dichotomy was really all that novel.
In a similar vein, as a chord constituent, a music function will
accept a chord constituent in the place of a prospective last music
argument.
It does not seem overly satisfactory that only the last such component
will be syntactically warped according to the surrounding. Perhaps
one should use different signatures in the first place.
Suggestions welcome.
Please review this at http://codereview.appspot.com/4815052/
Affected files:
M Documentation/extending/programming-interface.itely
M lily/parser.yy
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
