[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jean Abou Samra
Subject: Re: „Anonymous” properties, deafening engravers and font features
Date: Thu, 18 Nov 2021 22:21:14 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1

Le 18/11/2021 à 21:51, Valentin Petzel a écrit :

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:

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)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]