Thank you for clarifying my imprecise wording.
I think I now understand where my terminology was misleading. I was
mixing syntactic context (parser level) with semantic context
(translation level).
A small experiment made the distinction clearer to me:
\version "2.26.0"
\paper {
\key c \major
}
There is no parser error here. The syntax is accepted, but semantically
the command has no effect because there is no suitable
context/translator consuming the generated key-change-event.
On the other hand:
\version "2.26.0"
\score {
\key c \major c'
}
produces an error. My current understanding is that this happens because
the parser accepts a music expression in \score, but the structure
created here does not match the expected grammar.
Interestingly:
\version "2.26.0"
\score {
\key c \major
}
is accepted, which suggests that the parser is mainly concerned with
syntactic validity and not whether the resulting Music expression will
later have a meaningful translation.
So my original mistake was assuming from the user perspective that a
command like \key inside a \paper block would be a syntax error. From
LilyPond's architecture this is not necessarily true.
My goal is therefore not to replace or reproduce the parser, but to
provide semantic assistance in the editor. For example:
* lexical highlighting: "is this a known command?"
* syntactic highlighting: "can LilyPond parse this?"
* semantic highlighting/linting: "does this Music expression make sense
in the current context?"
Ideally, the editor could distinguish errors where LilyPond cannot parse
the file from cases where the file parses successfully but the resulting
Music expression cannot be meaningfully translated.
My current experiments suggest that introspection of the Music objects
generated by LilyPond may allow extracting some of this information
automatically.
Regarding:
defaultKey = \key a \major
I would not expect this to be a problem for the editor. I would store
the identifier "defaultKey" as a definition and provide navigation (e.g.
jumping to the definition with F2). The remaining question is how to
represent the semantic information of the expression after the `=` sign.
Best regards,
Christian
