Valentin Petzel <valen...@petzel.at> writes: > Hello, > > I have three ideas for maybe useful features for Lilypond: > > First, Lilypond is very strict about what values grob/context > properties can take. While this is generally a good thing it can be > hindering, as properties are more or less hard coded. So I suggest > that maybe we could have some sort of identifier for „custom” > properties that skip the type check. This would be useful for extended > scripting where we want to store arbitrary information.
That seems like a complete confused proposal to me since LilyPond is strict about the values of properties because it has to be able to _interpret_ them. If you want to define your _own_ properties without any constraint whatsoever (what is then going to be able to interpret just _any_ Scheme value you throw at it?), you can define them to be of type scheme? . > For example we might have Staves that should behave differently if > certain other Staves are present. E.g. if we have some splitted staves > and we want to have voices behave differently depending on whether > they are in a separate staff or in the common staff. So? > So for this it would be nice if we could simply save information in > the Staff context that tells us things like how many different Parts > we currently have in the Staff, for example. How are you going to do that without the value having _any_ predictable type or structure? > Second it would be very useful if we could somehow give engravers some > sort of filtering option that would allow us to make them not to > listen to certain events, so that we’d basically be able to > disable/enable engravers outside of withing the score, or even disable > engravers for certain Types of events or for events that fit some > condition (like having a certain tag). Engravers only listen to a given type of event. Removing events with a certain tag is done by the \removeWithTag command. So what is your proposal supposed to achieve exactly? > Third: Using font-features with Lilypond is a bit weird, as using \override > #'(font-features featureA featureB bla bla . ()) will override any previously > applied font-features. So I suggest adding markup functions addFontFeature > and > removeFontFeature like in the appended example to make this easier. I have no idea about font handling so I cannot say anything concerning that. > What are your takes on this? I don't see what you propose that isn't already covered. Perhaps some actual examples of what you want to achieve would help? -- David Kastrup
