Hi Harm,
Well, it's a little cheating involved :)
LilyPond does checks for grob-properties, you can't write
\override Grob.self-invited-property = ...
without "explaining" this `self-invited-property´ to LilyPond.
But details and bound-details are established properties taking alists
containing key-value-pairs of subproperties.
Adding a new one like `arrow-left´ will not disturb other procedures
reading `(bound-)details´, they simply don't look for the new ones
(ofcourse you need to care not to take a preserved one). There is no
checking of subproperties.
So I code frequently this way.
Thanks for the explanation!
I believe bound-details is more common for grobs with the
line-spanner-interface, but it makes no real difference, afaik.
I'm aware doing
arrow-left -> LEFT
arrow-right -> RIGHT
is not that elegant, but thee are two names needed with three options
LEFT/RIGHT/#f
I'll have to think over it.
But why not just a true/false flag?
arrow-left -> ##f (default) / ##t
arrow-right -> ##f (default) / ##t
At the moment, arrow-left = #RIGHT does something that might even be
turned into a useful arrow-tail, but that's not yet the case, and for
now, I think, "no tip / arrow tip" are the reasonable alternatives.
By the way, does the [bound-]details construct allow for nested
sub-properties? I ask because of the Glissando analogy where it's
.bound-details.left.arrow = ##f / ##t.
Lukas
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
