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

[Valentin Petzel]

Hello Jean, Hello Lukas,

I’ve just remembered why I was asking for stoppable engravers: A while ago 
there was a question about ties between different voices. Then someone (I 
think it was you Lukas?) suggested moving the Engraver from the Voice context 
to the Staff context. So then I thought that in such situations it would be 
very useful to shortly deactivate the engraver for Voice and activate it of 
Staff.

I have extended \with-font-feature to also take lists of features and to 
handle non string input (like a list of symbols). Also I have added a method 
to remove features by prepending them by -, so -smcp removes a previous smcp 
(which is not an uncommon way of handling this).

What do you think about this?

Cheers,
Valentin

Am Donnerstag, 18. November 2021, 22:21:14 CET schrieb 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#ne
> w-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

font-features.ly
Description: Text Data

signature.asc
Description: This is a digitally signed message part.