Lukas-Fabian Moser <l...@gmx.de> writes:
> Hi,
>
> sorry for the messed-up formatting. I try again:
>
> This is probably a very stupid question.
>
> During my work on updating blackmensural.ly I had to deal with custom
> grob and context properties. The original source for 2.12 did the
> following:
>
> %% ===============================================
> % declaring some custom properties
> %% ===============================================
>
> %% custom NoteHead property, for \override-able notehead style definitions
> #(set-object-property! 'mensural_glyphs 'backend-type? list?)
> #(set-object-property! 'mensural_glyphs 'backend-doc "current set of
> mensural display settings")
>
> %% custom Voice context property, needed for ligature assembly
> #(set-object-property! 'mensural_ligature_queue 'backend-type? list?)
> #(set-object-property! 'mensural_ligature_queue 'backend-doc "current
> set of note grobs to be assembled into a ligature")
> #(set-object-property! 'mensural_accidentals_queue 'backend-type? list?)
> #(set-object-property! 'mensural_accidentals_queue 'backend-doc
> "current set of accidentals to be collected for a ligature")
>
> %% custom entry in an event's 'tweak property
> #(set-object-property! 'mensural_tags 'backend-type? list?)
> #(set-object-property! 'mensural_tags 'backend-doc "various tags set
> in a notehead tweak to control mensural note display")
>
> The actual code then accessed
>
> a) mensural_glyphs with what amounts to \override
> NoteHead.mensural_glyphs = ...
> b) mensural_ligature_queue with (ly:context-property some-context
> 'mensural_ligature_queue) and (what amounts to) \set
> mensural_ligature_queue = ...
That is a horrible mistake mixing up grob properties and content
properties. This kind of mixup could lead to violent crashes and absurd
behavior when grob properties were still implemented as alists up until
commit e328b7a10ec1a4e13ba11104825bf54e027d0dd0
Author: David Kastrup <d...@gnu.org>
Date: Wed Jul 30 17:34:55 2014 +0200
Issue 2507: Stop the entanglement of context properties and grob property
internals
This introduces a semi-opaque structure Grob_properties meeting the
predicate ly:grob-properties? that is algorithmically handled at the C++
level via a wrapper structure Grob_property_info.
Encapsulating grob properties in that manner reduces the potential for
clashes and makes it easier to change algorithms and/or internal
representation.
While the principal distinction between context properties (one value
per context) and context-based grob property templates (one stack per
context) remains, at least the separation of the handling is more
pronounced.
in version 2.19.13
> c) mensural_tags with (ly:grob-property some-note 'mensural_tags) (and
> in a tweak).
>
> Part b) failed with current LilyPond: "can't find property type-check
> for `instrument' (translation-type?)" (I'm not sure if a) and c) work
> or just were not being in an active code path).
The error message is entirely unrelated to b). Any correlation must be
due to different code paths getting exercised. The problem is that a
context property "instrument" is being set without being defined, and
the change flagging the preexisting problem may possibly be
commit e44bc2cc48f9fb714603bdb5f8db532d55374087
Author: Neil Puttock <n.putt...@gmail.com>
Date: Thu Apr 30 20:29:09 2009 +0100
Add type-checking to \tweak.
in version 2.13.1
> Now, looking at scm/define-context-properties.scm and
> scm/define-grob-properties.scm that there seems to be a distinction:
>
> - Context properties (\set'table) are defined via
> (set-object-property! symbol 'translation-type? type?)
> - Grob properties (\override'able) are defined via
> (set-object-property! symbol 'backend-type? type?)
>
> Is this correct? And if so, when did this change between 2.12 and
> 2.22, seeing as the above code seems to have worked in 2011?
This has been around since at least 2.7 or longer. No change here.
> It works fine in 2.22 if I define mensural_ligature_queue using
> 'translation-type?
If you are accessing it via \set, it has to be defined via
translation-type.
--
David Kastrup
