[EMAIL PROTECTED] writes:
> It should be possible without any hacking to set properties in different
> contexts using the same macro.
>
> The burning reason for this is the accidental macros - but also other
> macros might come in handy. I.e. being able to say \clef F in start of
> the score to get F-clefs in all staves would be quite handy.
first of all, I don't see the point, in this sense: the number of
people that will deviate from the default accidentals is so small that
it doesn't warrant drastic additions to the syntax/semantics. (perhaps
I said this earlier, and you replied, but I forgot your motivation.)
> a) add aliasses to all context. I.e. "Current" to all contexts,
> "CurrentVoice" to all contexts except thread, "CurrentStaff" to all
> contexts except voice and thread.
> This way one can say
> \property CurrentStaff.blablabla
> to affect the current staff if it is present, otherwise the inntermost
> context.
>
> b) alternatively the \property command could be changed so that if the
> context was not found, instead of producing an error and do nothing, the
> operation was done on the innermost context. This way the clef-command
> would behave as desired without any changes to it.
It's not possible taht the context is not found; \property Foo.bar=
#bla really means
\context Foo [assign property in current context]
Secondly, what do you want
\score {
<
{ \clef bass c'4 }
{ c'4 }
>
}
to do ? Your suggestion would make bass clefs in both scores.
I think that the current behavior is just as bad as your suggestion. I
would prefer that the kind of advanced behavior you want be done with
an advanced feature such as evaluating Scheme code. I even recall
posting a suggestion on how to implement such a feature.
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.cs.uu.nl/~hanwen
_______________________________________________
Lilypond-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/lilypond-devel
