Xavier Scheuer <[email protected]> writes: > On 18 September 2011 00:43, David Kastrup <[email protected]> wrote: >> >> Use a music argument. This will, however, only work if the music >> function is recognizable as a postevent, namely as >> >> notToBarline = #(define-music-function >> (parser location grb) >> (ly:music?) >> #{ >> -\tweak #'to-barline ##f-$grb >> #}) >> >> { >> c1-\notToBarline \< | >> d4\! % etc. >> } > > Thanks for this answer. > So IIUC the dash between the end of the tweak and the ly:music? > argument is mandatory,
No. If you use notToBarline somewhere else than a postevent, you'll get a difference in behavior. Writing -$grb will give you a syntax error inside of notToBarline (because you gave put music in the place of a post event), writing $grb will pass the music right into tweak which will apply it without hesitation. If you want \notToBarline to still apply a tweak when used as a non-postevent, you'll write $grb instead -$grb. I am not overly fond of this sort of polymorphism. One consequence is that music functions used as postevents need one of -^_ before their call. > as well as the one between the note and the \notToBarline ? That one, unfortunately, is indispensible because of the mentioned polymorphism. >> At the current point of time, you can put postevents into variables, >> but music functions work as (and on) postevents only if declared as >> such. With the current framework, it would be reasonably simple to >> implement a define-event-function (if really wanted), but it does >> need support in parser and lexer. > > I would like to be able to get rid of the dash between the note and > \notToBarline . > But I do not think it is worth going into huge work only for me to > meet my aesthetic desire (but if someone else is interested in this > define-event-function and if this is implemented, I would be happy to > use it of course). ;-) For the last week I have been busy fighting shift/reduce and reduce/reduce conflicts trying to implement optional music function arguments in a sane and maintainable way. I am going to get a sane framework for this first and see where to go from there. The polymorphism stuff happens to be a real nuisance for implementing things. -- David Kastrup _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
