2011/9/18 David Kastrup <[email protected]>
> 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
Hi David,
I tried your suggestion (without any changes), but it didn't compile.
\version "2.14.2"
notToBarline = #(define-music-function
(parser location grb)
(ly:music?)
#{
-\tweak #'to-barline ##f-$grb
#})
{
c1-\notToBarline \< |
d4\! % etc.
}
The log states:
<string>:2:1: Fehler: syntax error, unexpected '-'
-\tweak #(quote to-barline) ##f-\lilyvartmpbg
<string>:2:32: Fehler: syntax error, unexpected '-'
-\tweak #(quote to-barline) ##f
-\lilyvartmpbg
Am I doing something wrong? Or should I use a higher version?
Cheers,
Harm
_______________________________________________
lilypond-user mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-user
