Note: Since English is not my native language, I have included the
original German version of my message at the end for additional clarity.
Regarding 1. Introspection function for the specification
---------------------------------------------------------
I am currently investigating whether the relationship between LilyPond
syntax and its internal structures can be extracted automatically.
The question is: In which context can a LilyPond command be applied?
For example:
\key name scale
So the desired lookup would be:
\key -> Allowed Context
At the moment I can do this manually by following the internal structures.
In the Internals documentation I find the Music type:
key-change-event
which is exactly what I need.
- Syntax:
\key name scale
- Music types: (key-change-event event)
- Accepted by: Key_engraver and Key_performer
I now understand that Engravers are responsible for graphical output,
while Performers are responsible for MIDI output.
Looking at Key_engraver I find:
- Music types accepted: key-change-event
- Contexts:
GregorianTranscriptionStaff,
InternalGregorianStaff,
InternalMensuralStaff,
KievanStaff,
MensuralStaff,
PetrucciStaff,
Staff,
VaticanaStaff
So I can infer the chain backwards:
\key-> key-change-event-> Key_engraver-> Staff (or specialized Staff
variants)
In short:
\key -> Staff
I assume that VaticanaStaff, MensuralStaff, etc. are specialized Staff
contexts with different default settings.
The only thing that is not completely clear to me is why \key also works
in a Voice context. My current assumption is that this is related to the
context hierarchy: the Music event is not necessarily handled only by
the immediate context, but can be consumed by suitable translators in
parent contexts.
For \clef this analysis becomes more difficult because the corresponding
Music type is not as obvious in the Internals documentation.
My idea is that the steps I am currently doing manually could probably
be automated with existing introspection facilities.
---------------------------------------------------------------------------------------------------------------------------
I can already automatically list all translators (Engravers/Performers)
and the Music types they accept.
I also suspect that the reverse mapping
Context -> Translator
can be extracted automatically from the existing context definitions.
The only step for which I have not found a direct introspection function
yet is:
LilyPond syntax -> Music type
for example:
\key -> key-change-event
I would especially like to ask David Kastrup whether he sees a suitable
way to implement such an introspection mechanism and whether this would
be something he might consider contributing.
Does such an internal mechanism already exist, which I have overlooked?
If not, would it make sense to add a small introspection function that
extracts this mapping from the Music definitions (define-music-type or
similar)?
In the end, this could allow generating the complete specification
needed by my syntax highlighter automatically.
This would also make the specification robust against future LilyPond
versions.
Would a manually maintained specification still be needed then?
Ideally, a manually written and reviewed reference specification could
serve as regression test data (Golden Master / Reference Data) to verify
that the automatically generated specification is still correct.
Best regards,
Christian
German version:
In der Hoffnung, dass es für uns alle leichter versändlich versuche ich
es mal in meiner Muttersprache am Ende der Mail.
Der erste Teil war übersetzt von ChatGBT.
zu 1. Introspektive Funktion für die Spezifikation
==================================================
Fragestellung: In welchem Kontext kann \key angewendet werden (\key ->
Allowed Context) ?
Dazu kann ich von Hand auf die Suche gehen.
In den Internals finde ich KeyChangeEvent - perfekt, danke!
Syntax: \key name scale.
types: '(key-change-event event)
Accepted by: Key_engraver and Key_performer.
Inzwischen verstehe, ich Engraver sind für die Grafik zuständig und
Performer für das MIDI.
Also unter Key_engraver finde ich:
Music types accepted: key-change-event
part of ..context(s) ...: GregorianTranscriptionStaff,
InternalGregorianStaff, InternalMensuralStaff, KievanStaff,
MensuralStaff, PetrucciStaff, Staff and
VaticanaStaff.
So kann ich also rückwärts Schlussfolgern:
\key -> key-change-event -> Key_engraver -> Staff
Kurz:
\key -> Staff
Ich nehme an VaticanaStaff und so weiter sind nur ein Staff mit
speziellen Einstellungen?
Warum \key dennoch im Kontext einer Voice akzeptiert wird kann ich nur
vermuten.
Vermutlich weil eine Voice implizit einen Top-Kontext sucht und
automatisch einen Staff und einen Score erzeugt? Oder wird das \key von
der Voice an den Staff durchgereicht? Nebenbei scheint mir, dass eine
StaffGroup nicht automaisch erzeugt wird, richtig?
Bei \clef wird dieses Vorgehen schwieriger, weil der entsprechende
Event/Typ nicht so offensichtlich in den Internals auftaucht.
Meine Idee: Was ich da von Hand mache, lässt sich durch verschiedene
Funktionen die bereits existieren automatisieren.
Eine Liste aller Engraver kann ich mir automatisch ausgeben lassen. Auch
die Events, die die Engraver konsumieren. Beides ist mir bereits gelungen.
Ich vermute auch der Schritt Kontext->Engraver lässt sich mit den
bereits vorhandenen Funktionen automatisieren?
Der einzige Schritt, für den ich bisher keine direkte
Introspektionsfunktion gefunden habe, ist:
\key -> key-change-event
Also die Zuordnung zwischen einer LilyPond-Eingabesyntax und dem
erzeugten Music-Typ.
Gibt es dafür bereits eine interne Möglichkeit, die ich übersehen habe?
Falls nicht, wäre es sinnvoll, eine kleine Introspektionsfunktion zu
ergänzen, die diese Zuordnung aus den Music-Definitionen
(define-music-type o.ä.) ausliest.
Am ende könnte man eine Funktion schreiben, die die komplette
Spezifikation, die mein Lexer für das Syntax-HighLighting benötigt
automatisch ausgibt.
Damit wäre die Sicherheit für alle zukünftigen Versionen gegeben. Ich
habe überlegt ob David Kastrup eine Möglichkeit sehen würde und Lust
hätte soetwas zu schreiben. Ich überlege zudem, ob man dafür öffentliche
Förderprogamme gewinnen könnte.
Brauche ich nun keine Spezifikation mehr von Hand schreiben?
Idealerweise könnte man die von Hand geschriebene und von euch
abgesegnete Spezifikation als Regression Test (Golden Master/ Reference
Data) nehmen, um zu prüfen, ob die automatische Funktion funktioniert.
Schöne Grüße
Christian
