Re: Questions regarding Specification and Lexer

Thank you for clarifying my imprecise wording.
I think I now understand where my terminology was misleading. I was=20
mixing syntactic context (parser level) with semantic context=20
(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=20
the command has no effect because there is no suitable=20
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=
=20
the parser accepts a music expression in \score, but the structure=20
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=20
syntactic validity and not whether the resulting Music expression will=20
later have a meaningful translation.

So my original mistake was assuming from the user perspective that a=20
command like \key inside a \paper block would be a syntax error. From=20
LilyPond's architecture this is not necessarily true.

My goal is therefore not to replace or reproduce the parser, but to=20
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=20
in the current context?"

Ideally, the editor could distinguish errors where LilyPond cannot parse=
=20
the file from cases where the file parses successfully but the resulting=
=20
Music expression cannot be meaningfully translated.

My current experiments suggest that introspection of the Music objects=20
generated by LilyPond may allow extracting some of this information=20
automatically.

Regarding:

defaultKey =3D \key a \major

I would not expect this to be a problem for the editor. I would store=20
the identifier "defaultKey" as a definition and provide navigation (e.g.=
=20
jumping to the definition with F2). The remaining question is how to=20
represent the semantic information of the expression after the `=3D` sign.

Best regards,
Christian