"C. Stroppel" <[email protected]> writes:
> 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.
You really need to work up your understanding. A \score accepts _one_
music expression inside of its braces. "\key c \major" is one such
expression, "c'" is a second one. You can just add another level of
braces to create a single expression:
\score { { \key c \major c' } }
> 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.
That is kind of the definition of a parser. Note that when writing
{ c' e' g' }
\layout {
\clef "bass"
}
the \clef has an effect, while a key statement in that place hasn't.
The difference is one in how the two music expressions are actually
implemented: \layout tentatively accepts arbitrary music expressions and
converts any property settings to appropriate context defaults. \key is
implemented as a separate music event, \clef is implemented as a number
of property settings.
> 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.
The main problem with LilyPond is semantic tie-ins of which music
functions and their arguments tend to be the most wildly flexible ones.
For that reason it makes sense to hover up the predefined music function
definitions and make the parser aware of them. How to deal with
user-defined ones is a different question.
It is not necessary to really highlight everything that one can squeeze
through the parser: there are just things that are a bad idea.
Sometimes there may be sense in highlighting them toshow why they are a
bad idea.
For example, the following is valid input:
{ f = \key f \major }
\language "italiano"
f = \key fa \major
but few people will expect the output.
--
David Kastrup
