Re: „Anonymous” properties, deafening engravers and font features

[David Kastrup]

Valentin Petzel <valentin@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