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

[Jean Abou Samra]

Le 18/11/2021 à 21:51, Valentin Petzel a écrit :
> Hello,
>
> I have three ideas for maybe useful features for Lilypond:

Let's keep this one here, but next time it would be
a good idea to send feature requests to -devel instead.
Not all developers read -user.


> 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.
>
> 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 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.
>
> For example we could handle properties that begin with „custom” as custom
> properties, so we could say \override Staff.custom-my-property = something.


You can define new properties with a predicate as
explained here:

https://extending-lilypond.readthedocs.io/en/latest/properties-types.html#new-properties

I don't think we would want to make custom engravers
different from the default ones here, not the least
because any user-written engraver is a candidate for
being included in the core. If your property really
accepts anything, just give it the predicate scheme? .


> 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).

What is the use case?

It doesn't sound bad, but I doubt it will fully answer
problems related to grobs created not in reaction to
events but in reaction to other grobs via acknowledgers.
So my own vague take on "pushing grobs to contexts",
part combining, cross-staff, and all that would rather
be adding the ability to start and stop engravers midway.
Not that I have any more precise ideas than this though.


> 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.
>
> What are your takes on this?

Sounds useful. \removeFontFeature sounds more like a
specialized use case though. I'd add just \with-font-feature
(dashes are the convention for markup commands). Also
note that you can rewrite it more simply (in my opinion) as

#(define-markup-command (with-font-feature layout props feat m) (string? 
markup?)
   #:properties ((font-features '()))
   (interpret-markup layout
                     `(((font-features . (,feat . ,font-features))) . 
,props)
                     m))

Best,
Jean