Re: Is there a get-context procedure?

[Richard Shann]

On Wed, 2014-09-24 at 21:05 -0700, Paul Morris wrote:
> Richard Shann-2 wrote
> > The chordRootNamer procedure (which is itself a ChordNames context
> > property) is not passed the context as a parameter, so my question is
> > how do I reference the context? Is there some variable or procedure for
> > accessing the ChordNames context (or perhaps it should be the context
> > that the call has been made in, if that makes sense)?
> 
> Hi Richard, 
> I don't know of any.  The way I've done this kind of thing (access a context
> and context property) is from a custom engraver that is part of a given
> context and so it has access to it.  Perhaps a custom Scheme engraver that
> takes its cues from the Chord_name_engraver would work?  
> 
> Another possibility might be to use a custom grob property instead, and
> then, for example, you can access that custom value from the grob as you
> override/modify other properties of that grob. (Maybe say resizing a grob's
> stencil by a given amount stored in the custom grob property, if that works
> and will do what you want?)

Thank you for these comments. I have been working purely in
define-context-properties.scm and chord-ignatzek-names.scm which hasn't
exposed me to engravers or grobs. I added a chordInversionNamer on the
pattern of the chordNoteNamer in the first of these files and called it
from the second of these, and the mechanism is working to create chord
inversions where the note name appears below the root name rather than
at the end of the chord symbol (thus providing a more compact form -
trading vertical for horizontal space).
Following up your response I've looked into the source code and I see
that the property chordNoteNamer (that my new property
chordInversionNamer is modelled on) has a hard-coded presence in
chord-name-engraver.cc via this code:

ADD_TRANSLATOR (Chord_name_engraver,
                /* doc */
                "Catch note and rest events and generate the appropriate
chordname.",

                /* create */
                "ChordName ",

                /* read */
                "chordChanges "
                "chordNameExceptions "
                "chordNameFunction "
                "chordNoteNamer "
                "chordRootNamer "
                "chordNameExceptions "
                "lastChord "
                "majorSevenSymbol "
                "noChordSymbol ",

                /* write */
                "lastChord "
               );

so I guess from this that my additional property chordInversionNamer has
a different status to chordNoteNamer, but it is nevertheless called with
the same arguments - I can only guess that all procedure properties in
this (translator? engraver? context?) are. The built-in chordNoteNamer
is initialized in scm/chord-name.scm to

(define-public (note-name->markup pitch lowercase?)
  "Return pitch markup for @var{pitch}."
  (make-line-markup
   (list
    (make-simple-markup
     (conditional-string-downcase
      (vector-ref #("C" "D" "E" "F" "G" "A" "B") (ly:pitch-notename pitch))
      lowercase?))
    (accidental->markup (ly:pitch-alteration pitch)))))

but this makes no access to properties of the (translator? engraver?
context?) ...

Thinking about this after receiving your email, I realize that
ultimately what I am trying to do is access the font-size that is being
used for the markup being generated. Perhaps this is a simpler question
- can a markup be constructed to change depending on the font-size it is
being invoked with?

Richard