docs: highlight all lexer keywords in the playground and in-repo grammars

[prql-bot]

Problem

#6207 brought the two Handlebars/highlight.js keyword lists in line with the lexer's keyword parser, but the same drift remains in the grammars this repo ships. Against the ten keywords the lexer defines (let, into, case, prql, type, module, internal, func, import, enum):

Grammar	Missing
web/playground/src/workbench/prql-syntax.js (Monarch)	into, type, module, internal, func, import, enum
grammars/GtkSourceView/prql.lang	into, case, type, module, internal, func, import, enum
grammars/CotEditor/PRQL.yaml	into, type, internal, func, import, enum
grammars/KSyntaxHighlighting/prql.xml	into, case, internal, func, import, enum

The playground one is the most visible: module, type and into render as plain identifiers on prql-lang.org today. The emacs and nano grammars already carry the full set, so they're untouched.

Solution

Add the missing entries to each keyword list, with the same "keep in sync with the lexer" comment #6207 added, so the next drift is easier to spot.

Two grammars also needed their styling adjusting so the added keywords actually render as keywords:

• GtkSourceView had a single declarations context (style-ref="declaration", which maps to def:type), so func/case/into/import would have rendered in the same colour as int and timestamp, while the file's keyword style — mapping to def:keyword — was declared but referenced by nothing. That context is now keywords, styled keyword, holding all ten; the unused declaration style is dropped. prql moves out of built-in-object into it, which brings the file in line with emacs (prql-other-keywords → font-lock-keyword-face), nano and KSyntaxHighlighting, all of which put the same ten on one keyword face.
• KSyntaxHighlighting holds prql in a modules_builtin list that no context references, so it wasn't highlighted at all; it's now in the new keywords list, alongside import in imports. Both map to the same Keyword attribute as the lists beside them. The <language>version is bumped 0 → 1, per KDE's contributing note ("If you are modifying an existing syntax definition XML file, you must increase the version number of the language").

CotEditor and the playground keep their existing groupings — both already carried prql on a keyword list.

Testing

No automated coverage exists for these grammars (#2052 tracks that), so verification is structural: both XML files parse, every style the GtkSourceView file declares is now referenced by a context, the CotEditor YAML parses to the expected 20-entry keyword list, and prettier passes on the JS and YAML.

Found during the nightly rolling survey of grammars/GtkSourceView/prql.lang and web/playground/src/workbench/monaco-theme.json.

[prql-bot]

Two observations on the grammar files, one of which means the PR doesn't quite reach its own goal.

prql still isn't highlighted in the KSyntaxHighlighting grammar. The new comment says "prql is a built-in module", but the modules_builtin list holding it isn't referenced by any context — the only keyword rules in the Normal context are types, specialvars, builtinfuncs, declarations, letExpressions, imports and the newly-added keywords (date_functions, text_functions and durations are orphaned the same way). So prql renders as a plain identifier in Kate, and the comment points the next person checking for drift at a list that does nothing. The inline suggestion adds it to the new keywords list; the alternative — referencing modules_builtin from Normal — needs a new itemData and would be shadowed for date/text, which the types rule already claims a few lines earlier.

In GtkSourceView all nine land on style-ref="declaration", which maps to def:type.func, case, into and import will render in the same colour as int and timestamp, while the file declares <style id="keyword" … map-to="def:keyword"/> that nothing references (grep style-ref= prql.lang returns every style except keyword). The other three grammars here put these tokens on a keyword token/attribute, and emacs' prql-other-keywords — the same ten — uses font-lock-keyword-face. A second context styled keyword, mirroring the new keywords list this PR adds on the KSyntaxHighlighting side, would be more consistent; whether let/type/module move with it is a styling call, so leaving it rather than pushing one.

Two smaller things:

• prql.xml still carries version="0", unchanged since the file was added, and this is the first content change to it. I believe KSyntaxHighlighting selects among duplicate definitions of a language by that attribute, so it's conventionally incremented on each edit — I couldn't reach docs.kde.org from CI to confirm the exact rule, hence flagging rather than suggesting.
• Four grammars drifted simultaneously here. The sync comments make the next drift easier to spot but nothing fails when it happens, and test-grammars only covers lezer and raku. keyword() spells its ten out inline; lifting them into a const would let a small test assert each grammar file mentions each keyword — cheap coverage for the part of #2052 that bit here.

[prql-bot]

Thanks — both grammar points were real; pushed 2e54e6a and 9ebdbf3.

GtkSourceView styling. Made the call and moved all ten onto keyword: the declarations context is now keywords, style-ref="keyword", the unreferenced declaration style is dropped, and prql moves out of built-in-object into it. That matches emacs (prql-other-keywords → font-lock-keyword-face), nano (one color yellow line for the same ten) and KSyntaxHighlighting (every keyword list → the Keyword attribute), so all five grammars now put the lexer's keywords on one face. Every style the file declares is referenced by a context again, which is what flagged the problem in the first place.

version="0". Confirmed and bumped to 1 — KDE's contributing notes say "If you are modifying an existing syntax definition XML file, you must increase the version number of the language." (docs.kde.org is unreachable from CI, but the repo README is fetchable via the API.)

A drift test. Agreed it's the right fix for the class of bug, but it's independently revertable from this PR and I'm at five open PRs, so noting the shape here rather than opening a sixth: lift the ten just(..) arms in keyword() into a pub const KEYWORDS: [&str; 10], drive the parser from it, and assert in a test that each grammar file under grammars/ carrying a keyword list, plus web/playground/src/workbench/prql-syntax.js, contains every entry. A substring check over the file text is crude but is exactly the assertion that would have failed here, and it needs no per-format parser. #2052 is the tracking issue.

Not addressed: modules_builtin, date_functions, text_functions and durations in prql.xml are all orphaned lists no context references — pre-existing, and untangling them means new itemData entries and resolving the shadowing against types.

[prql-bot]

Problem

#6207 brought the two Handlebars/highlight.js keyword lists in line with the lexer's keyword parser, but the same drift remains in the grammars this repo ships. Against the ten keywords the lexer defines (let, into, case, prql, type, module, internal, func, import, enum):

Grammar	Missing
web/playground/src/workbench/prql-syntax.js (Monarch)	into, type, module, internal, func, import, enum
grammars/GtkSourceView/prql.lang	into, case, type, module, internal, func, import, enum
grammars/CotEditor/PRQL.yaml	into, type, internal, func, import, enum
grammars/KSyntaxHighlighting/prql.xml	into, case, internal, func, import, enum

The playground one is the most visible: module, type and into render as plain identifiers on prql-lang.org today. The emacs and nano grammars already carry the full set, so they're untouched.

Solution

Add the missing entries to each keyword list, with the same "keep in sync with the lexer" comment #6207 added, so the next drift is easier to spot.

Two grammars also needed their styling adjusting so the added keywords actually render as keywords:

• GtkSourceView had a single declarations context (style-ref="declaration", which maps to def:type), so func/case/into/import would have rendered in the same colour as int and timestamp, while the file's keyword style — mapping to def:keyword — was declared but referenced by nothing. That context is now keywords, styled keyword, holding all ten; the unused declaration style is dropped. prql moves out of built-in-object into it, which brings the file in line with emacs (prql-other-keywords → font-lock-keyword-face), nano and KSyntaxHighlighting, all of which put the same ten on one keyword face.
• KSyntaxHighlighting holds prql in a modules_builtin list that no context references, so it wasn't highlighted at all; it's now in the new keywords list, alongside import in imports. Both map to the same Keyword attribute as the lists beside them. The <language>version is bumped 0 → 1, per KDE's contributing note ("If you are modifying an existing syntax definition XML file, you must increase the version number of the language").

CotEditor and the playground keep their existing groupings — both already carried prql on a keyword list.

Testing

No automated coverage exists for these grammars (#2052 tracks that), so verification is structural: both XML files parse, every style the GtkSourceView file declares is now referenced by a context, the CotEditor YAML parses to the expected 20-entry keyword list, and prettier passes on the JS and YAML.

Found during the nightly rolling survey of grammars/GtkSourceView/prql.lang and web/playground/src/workbench/monaco-theme.json.

[prql-bot]

Two observations on the grammar files, one of which means the PR doesn't quite reach its own goal.

prql still isn't highlighted in the KSyntaxHighlighting grammar. The new comment says "prql is a built-in module", but the modules_builtin list holding it isn't referenced by any context — the only keyword rules in the Normal context are types, specialvars, builtinfuncs, declarations, letExpressions, imports and the newly-added keywords (date_functions, text_functions and durations are orphaned the same way). So prql renders as a plain identifier in Kate, and the comment points the next person checking for drift at a list that does nothing. The inline suggestion adds it to the new keywords list; the alternative — referencing modules_builtin from Normal — needs a new itemData and would be shadowed for date/text, which the types rule already claims a few lines earlier.

In GtkSourceView all nine land on style-ref="declaration", which maps to def:type.func, case, into and import will render in the same colour as int and timestamp, while the file declares <style id="keyword" … map-to="def:keyword"/> that nothing references (grep style-ref= prql.lang returns every style except keyword). The other three grammars here put these tokens on a keyword token/attribute, and emacs' prql-other-keywords — the same ten — uses font-lock-keyword-face. A second context styled keyword, mirroring the new keywords list this PR adds on the KSyntaxHighlighting side, would be more consistent; whether let/type/module move with it is a styling call, so leaving it rather than pushing one.

Two smaller things:

• prql.xml still carries version="0", unchanged since the file was added, and this is the first content change to it. I believe KSyntaxHighlighting selects among duplicate definitions of a language by that attribute, so it's conventionally incremented on each edit — I couldn't reach docs.kde.org from CI to confirm the exact rule, hence flagging rather than suggesting.
• Four grammars drifted simultaneously here. The sync comments make the next drift easier to spot but nothing fails when it happens, and test-grammars only covers lezer and raku. keyword() spells its ten out inline; lifting them into a const would let a small test assert each grammar file mentions each keyword — cheap coverage for the part of #2052 that bit here.

[prql-bot]

Thanks — both grammar points were real; pushed 2e54e6a and 9ebdbf3.

GtkSourceView styling. Made the call and moved all ten onto keyword: the declarations context is now keywords, style-ref="keyword", the unreferenced declaration style is dropped, and prql moves out of built-in-object into it. That matches emacs (prql-other-keywords → font-lock-keyword-face), nano (one color yellow line for the same ten) and KSyntaxHighlighting (every keyword list → the Keyword attribute), so all five grammars now put the lexer's keywords on one face. Every style the file declares is referenced by a context again, which is what flagged the problem in the first place.

version="0". Confirmed and bumped to 1 — KDE's contributing notes say "If you are modifying an existing syntax definition XML file, you must increase the version number of the language." (docs.kde.org is unreachable from CI, but the repo README is fetchable via the API.)

A drift test. Agreed it's the right fix for the class of bug, but it's independently revertable from this PR and I'm at five open PRs, so noting the shape here rather than opening a sixth: lift the ten just(..) arms in keyword() into a pub const KEYWORDS: [&str; 10], drive the parser from it, and assert in a test that each grammar file under grammars/ carrying a keyword list, plus web/playground/src/workbench/prql-syntax.js, contains every entry. A substring check over the file text is crude but is exactly the assertion that would have failed here, and it needs no per-format parser. #2052 is the tracking issue.

Not addressed: modules_builtin, date_functions, text_functions and durations in prql.xml are all orphaned lists no context references — pre-existing, and untangling them means new itemData entries and resolving the shadowing against types.

[prql-bot]

Problem

#6207 brought the two Handlebars/highlight.js keyword lists in line with the lexer's keyword parser, but the same drift remains in the grammars this repo ships. Against the ten keywords the lexer defines (let, into, case, prql, type, module, internal, func, import, enum):

Grammar	Missing
web/playground/src/workbench/prql-syntax.js (Monarch)	into, type, module, internal, func, import, enum
grammars/GtkSourceView/prql.lang	into, case, type, module, internal, func, import, enum
grammars/CotEditor/PRQL.yaml	into, type, internal, func, import, enum
grammars/KSyntaxHighlighting/prql.xml	into, case, internal, func, import, enum

The playground one is the most visible: module, type and into render as plain identifiers on prql-lang.org today. The emacs and nano grammars already carry the full set, so they're untouched.

Solution

Add the missing entries to each keyword list, with the same "keep in sync with the lexer" comment #6207 added, so the next drift is easier to spot.

Two grammars also needed their styling adjusting so the added keywords actually render as keywords:

• GtkSourceView had a single declarations context (style-ref="declaration", which maps to def:type), so func/case/into/import would have rendered in the same colour as int and timestamp, while the file's keyword style — mapping to def:keyword — was declared but referenced by nothing. That context is now keywords, styled keyword, holding all ten; the unused declaration style is dropped. prql moves out of built-in-object into it, which brings the file in line with emacs (prql-other-keywords → font-lock-keyword-face), nano and KSyntaxHighlighting, all of which put the same ten on one keyword face.
• KSyntaxHighlighting holds prql in a modules_builtin list that no context references, so it wasn't highlighted at all; it's now in the new keywords list, alongside import in imports. Both map to the same Keyword attribute as the lists beside them. The <language>version is bumped 0 → 1, per KDE's contributing note ("If you are modifying an existing syntax definition XML file, you must increase the version number of the language").

CotEditor and the playground keep their existing groupings — both already carried prql on a keyword list.

Testing

No automated coverage exists for these grammars (#2052 tracks that), so verification is structural: both XML files parse, every style the GtkSourceView file declares is now referenced by a context, the CotEditor YAML parses to the expected 20-entry keyword list, and prettier passes on the JS and YAML.

Found during the nightly rolling survey of grammars/GtkSourceView/prql.lang and web/playground/src/workbench/monaco-theme.json.

[prql-bot]

Two observations on the grammar files, one of which means the PR doesn't quite reach its own goal.

prql still isn't highlighted in the KSyntaxHighlighting grammar. The new comment says "prql is a built-in module", but the modules_builtin list holding it isn't referenced by any context — the only keyword rules in the Normal context are types, specialvars, builtinfuncs, declarations, letExpressions, imports and the newly-added keywords (date_functions, text_functions and durations are orphaned the same way). So prql renders as a plain identifier in Kate, and the comment points the next person checking for drift at a list that does nothing. The inline suggestion adds it to the new keywords list; the alternative — referencing modules_builtin from Normal — needs a new itemData and would be shadowed for date/text, which the types rule already claims a few lines earlier.

In GtkSourceView all nine land on style-ref="declaration", which maps to def:type.func, case, into and import will render in the same colour as int and timestamp, while the file declares <style id="keyword" … map-to="def:keyword"/> that nothing references (grep style-ref= prql.lang returns every style except keyword). The other three grammars here put these tokens on a keyword token/attribute, and emacs' prql-other-keywords — the same ten — uses font-lock-keyword-face. A second context styled keyword, mirroring the new keywords list this PR adds on the KSyntaxHighlighting side, would be more consistent; whether let/type/module move with it is a styling call, so leaving it rather than pushing one.

Two smaller things:

• prql.xml still carries version="0", unchanged since the file was added, and this is the first content change to it. I believe KSyntaxHighlighting selects among duplicate definitions of a language by that attribute, so it's conventionally incremented on each edit — I couldn't reach docs.kde.org from CI to confirm the exact rule, hence flagging rather than suggesting.
• Four grammars drifted simultaneously here. The sync comments make the next drift easier to spot but nothing fails when it happens, and test-grammars only covers lezer and raku. keyword() spells its ten out inline; lifting them into a const would let a small test assert each grammar file mentions each keyword — cheap coverage for the part of #2052 that bit here.

[prql-bot]

Thanks — both grammar points were real; pushed 2e54e6a and 9ebdbf3.

GtkSourceView styling. Made the call and moved all ten onto keyword: the declarations context is now keywords, style-ref="keyword", the unreferenced declaration style is dropped, and prql moves out of built-in-object into it. That matches emacs (prql-other-keywords → font-lock-keyword-face), nano (one color yellow line for the same ten) and KSyntaxHighlighting (every keyword list → the Keyword attribute), so all five grammars now put the lexer's keywords on one face. Every style the file declares is referenced by a context again, which is what flagged the problem in the first place.

version="0". Confirmed and bumped to 1 — KDE's contributing notes say "If you are modifying an existing syntax definition XML file, you must increase the version number of the language." (docs.kde.org is unreachable from CI, but the repo README is fetchable via the API.)

A drift test. Agreed it's the right fix for the class of bug, but it's independently revertable from this PR and I'm at five open PRs, so noting the shape here rather than opening a sixth: lift the ten just(..) arms in keyword() into a pub const KEYWORDS: [&str; 10], drive the parser from it, and assert in a test that each grammar file under grammars/ carrying a keyword list, plus web/playground/src/workbench/prql-syntax.js, contains every entry. A substring check over the file text is crude but is exactly the assertion that would have failed here, and it needs no per-format parser. #2052 is the tracking issue.

Not addressed: modules_builtin, date_functions, text_functions and durations in prql.xml are all orphaned lists no context references — pre-existing, and untangling them means new itemData entries and resolving the shadowing against types.

[prql-bot]

Problem

#6207 brought the two Handlebars/highlight.js keyword lists in line with the lexer's keyword parser, but the same drift remains in the grammars this repo ships. Against the ten keywords the lexer defines (let, into, case, prql, type, module, internal, func, import, enum):

Grammar	Missing
web/playground/src/workbench/prql-syntax.js (Monarch)	into, type, module, internal, func, import, enum
grammars/GtkSourceView/prql.lang	into, case, type, module, internal, func, import, enum
grammars/CotEditor/PRQL.yaml	into, type, internal, func, import, enum
grammars/KSyntaxHighlighting/prql.xml	into, case, internal, func, import, enum

The playground one is the most visible: module, type and into render as plain identifiers on prql-lang.org today. The emacs and nano grammars already carry the full set, so they're untouched.

Solution

Add the missing entries to each keyword list, with the same "keep in sync with the lexer" comment #6207 added, so the next drift is easier to spot.

Two grammars also needed their styling adjusting so the added keywords actually render as keywords:

• GtkSourceView had a single declarations context (style-ref="declaration", which maps to def:type), so func/case/into/import would have rendered in the same colour as int and timestamp, while the file's keyword style — mapping to def:keyword — was declared but referenced by nothing. That context is now keywords, styled keyword, holding all ten; the unused declaration style is dropped. prql moves out of built-in-object into it, which brings the file in line with emacs (prql-other-keywords → font-lock-keyword-face), nano and KSyntaxHighlighting, all of which put the same ten on one keyword face.
• KSyntaxHighlighting holds prql in a modules_builtin list that no context references, so it wasn't highlighted at all; it's now in the new keywords list, alongside import in imports. Both map to the same Keyword attribute as the lists beside them. The <language>version is bumped 0 → 1, per KDE's contributing note ("If you are modifying an existing syntax definition XML file, you must increase the version number of the language").

CotEditor and the playground keep their existing groupings — both already carried prql on a keyword list.

Testing

No automated coverage exists for these grammars (#2052 tracks that), so verification is structural: both XML files parse, every style the GtkSourceView file declares is now referenced by a context, the CotEditor YAML parses to the expected 20-entry keyword list, and prettier passes on the JS and YAML.

Found during the nightly rolling survey of grammars/GtkSourceView/prql.lang and web/playground/src/workbench/monaco-theme.json.

[prql-bot]

Two observations on the grammar files, one of which means the PR doesn't quite reach its own goal.

prql still isn't highlighted in the KSyntaxHighlighting grammar. The new comment says "prql is a built-in module", but the modules_builtin list holding it isn't referenced by any context — the only keyword rules in the Normal context are types, specialvars, builtinfuncs, declarations, letExpressions, imports and the newly-added keywords (date_functions, text_functions and durations are orphaned the same way). So prql renders as a plain identifier in Kate, and the comment points the next person checking for drift at a list that does nothing. The inline suggestion adds it to the new keywords list; the alternative — referencing modules_builtin from Normal — needs a new itemData and would be shadowed for date/text, which the types rule already claims a few lines earlier.

In GtkSourceView all nine land on style-ref="declaration", which maps to def:type.func, case, into and import will render in the same colour as int and timestamp, while the file declares <style id="keyword" … map-to="def:keyword"/> that nothing references (grep style-ref= prql.lang returns every style except keyword). The other three grammars here put these tokens on a keyword token/attribute, and emacs' prql-other-keywords — the same ten — uses font-lock-keyword-face. A second context styled keyword, mirroring the new keywords list this PR adds on the KSyntaxHighlighting side, would be more consistent; whether let/type/module move with it is a styling call, so leaving it rather than pushing one.

Two smaller things:

• prql.xml still carries version="0", unchanged since the file was added, and this is the first content change to it. I believe KSyntaxHighlighting selects among duplicate definitions of a language by that attribute, so it's conventionally incremented on each edit — I couldn't reach docs.kde.org from CI to confirm the exact rule, hence flagging rather than suggesting.
• Four grammars drifted simultaneously here. The sync comments make the next drift easier to spot but nothing fails when it happens, and test-grammars only covers lezer and raku. keyword() spells its ten out inline; lifting them into a const would let a small test assert each grammar file mentions each keyword — cheap coverage for the part of #2052 that bit here.

[prql-bot]

Thanks — both grammar points were real; pushed 2e54e6a and 9ebdbf3.

GtkSourceView styling. Made the call and moved all ten onto keyword: the declarations context is now keywords, style-ref="keyword", the unreferenced declaration style is dropped, and prql moves out of built-in-object into it. That matches emacs (prql-other-keywords → font-lock-keyword-face), nano (one color yellow line for the same ten) and KSyntaxHighlighting (every keyword list → the Keyword attribute), so all five grammars now put the lexer's keywords on one face. Every style the file declares is referenced by a context again, which is what flagged the problem in the first place.

version="0". Confirmed and bumped to 1 — KDE's contributing notes say "If you are modifying an existing syntax definition XML file, you must increase the version number of the language." (docs.kde.org is unreachable from CI, but the repo README is fetchable via the API.)

A drift test. Agreed it's the right fix for the class of bug, but it's independently revertable from this PR and I'm at five open PRs, so noting the shape here rather than opening a sixth: lift the ten just(..) arms in keyword() into a pub const KEYWORDS: [&str; 10], drive the parser from it, and assert in a test that each grammar file under grammars/ carrying a keyword list, plus web/playground/src/workbench/prql-syntax.js, contains every entry. A substring check over the file text is crude but is exactly the assertion that would have failed here, and it needs no per-format parser. #2052 is the tracking issue.

Not addressed: modules_builtin, date_functions, text_functions and durations in prql.xml are all orphaned lists no context references — pre-existing, and untangling them means new itemData entries and resolving the shadowing against types.

[prql-bot]

Problem

#6207 brought the two Handlebars/highlight.js keyword lists in line with the lexer's keyword parser, but the same drift remains in the grammars this repo ships. Against the ten keywords the lexer defines (let, into, case, prql, type, module, internal, func, import, enum):

Grammar	Missing
web/playground/src/workbench/prql-syntax.js (Monarch)	into, type, module, internal, func, import, enum
grammars/GtkSourceView/prql.lang	into, case, type, module, internal, func, import, enum
grammars/CotEditor/PRQL.yaml	into, type, internal, func, import, enum
grammars/KSyntaxHighlighting/prql.xml	into, case, internal, func, import, enum

The playground one is the most visible: module, type and into render as plain identifiers on prql-lang.org today. The emacs and nano grammars already carry the full set, so they're untouched.

Solution

Add the missing entries to each keyword list, with the same "keep in sync with the lexer" comment #6207 added, so the next drift is easier to spot.

Two grammars also needed their styling adjusting so the added keywords actually render as keywords:

• GtkSourceView had a single declarations context (style-ref="declaration", which maps to def:type), so func/case/into/import would have rendered in the same colour as int and timestamp, while the file's keyword style — mapping to def:keyword — was declared but referenced by nothing. That context is now keywords, styled keyword, holding all ten; the unused declaration style is dropped. prql moves out of built-in-object into it, which brings the file in line with emacs (prql-other-keywords → font-lock-keyword-face), nano and KSyntaxHighlighting, all of which put the same ten on one keyword face.
• KSyntaxHighlighting holds prql in a modules_builtin list that no context references, so it wasn't highlighted at all; it's now in the new keywords list, alongside import in imports. Both map to the same Keyword attribute as the lists beside them. The <language>version is bumped 0 → 1, per KDE's contributing note ("If you are modifying an existing syntax definition XML file, you must increase the version number of the language").

CotEditor and the playground keep their existing groupings — both already carried prql on a keyword list.

Testing

No automated coverage exists for these grammars (#2052 tracks that), so verification is structural: both XML files parse, every style the GtkSourceView file declares is now referenced by a context, the CotEditor YAML parses to the expected 20-entry keyword list, and prettier passes on the JS and YAML.

Found during the nightly rolling survey of grammars/GtkSourceView/prql.lang and web/playground/src/workbench/monaco-theme.json.

[prql-bot]

Two observations on the grammar files, one of which means the PR doesn't quite reach its own goal.

prql still isn't highlighted in the KSyntaxHighlighting grammar. The new comment says "prql is a built-in module", but the modules_builtin list holding it isn't referenced by any context — the only keyword rules in the Normal context are types, specialvars, builtinfuncs, declarations, letExpressions, imports and the newly-added keywords (date_functions, text_functions and durations are orphaned the same way). So prql renders as a plain identifier in Kate, and the comment points the next person checking for drift at a list that does nothing. The inline suggestion adds it to the new keywords list; the alternative — referencing modules_builtin from Normal — needs a new itemData and would be shadowed for date/text, which the types rule already claims a few lines earlier.

In GtkSourceView all nine land on style-ref="declaration", which maps to def:type.func, case, into and import will render in the same colour as int and timestamp, while the file declares <style id="keyword" … map-to="def:keyword"/> that nothing references (grep style-ref= prql.lang returns every style except keyword). The other three grammars here put these tokens on a keyword token/attribute, and emacs' prql-other-keywords — the same ten — uses font-lock-keyword-face. A second context styled keyword, mirroring the new keywords list this PR adds on the KSyntaxHighlighting side, would be more consistent; whether let/type/module move with it is a styling call, so leaving it rather than pushing one.

Two smaller things:

• prql.xml still carries version="0", unchanged since the file was added, and this is the first content change to it. I believe KSyntaxHighlighting selects among duplicate definitions of a language by that attribute, so it's conventionally incremented on each edit — I couldn't reach docs.kde.org from CI to confirm the exact rule, hence flagging rather than suggesting.
• Four grammars drifted simultaneously here. The sync comments make the next drift easier to spot but nothing fails when it happens, and test-grammars only covers lezer and raku. keyword() spells its ten out inline; lifting them into a const would let a small test assert each grammar file mentions each keyword — cheap coverage for the part of #2052 that bit here.

[prql-bot]

Thanks — both grammar points were real; pushed 2e54e6a and 9ebdbf3.

GtkSourceView styling. Made the call and moved all ten onto keyword: the declarations context is now keywords, style-ref="keyword", the unreferenced declaration style is dropped, and prql moves out of built-in-object into it. That matches emacs (prql-other-keywords → font-lock-keyword-face), nano (one color yellow line for the same ten) and KSyntaxHighlighting (every keyword list → the Keyword attribute), so all five grammars now put the lexer's keywords on one face. Every style the file declares is referenced by a context again, which is what flagged the problem in the first place.

version="0". Confirmed and bumped to 1 — KDE's contributing notes say "If you are modifying an existing syntax definition XML file, you must increase the version number of the language." (docs.kde.org is unreachable from CI, but the repo README is fetchable via the API.)

A drift test. Agreed it's the right fix for the class of bug, but it's independently revertable from this PR and I'm at five open PRs, so noting the shape here rather than opening a sixth: lift the ten just(..) arms in keyword() into a pub const KEYWORDS: [&str; 10], drive the parser from it, and assert in a test that each grammar file under grammars/ carrying a keyword list, plus web/playground/src/workbench/prql-syntax.js, contains every entry. A substring check over the file text is crude but is exactly the assertion that would have failed here, and it needs no per-format parser. #2052 is the tracking issue.

Not addressed: modules_builtin, date_functions, text_functions and durations in prql.xml are all orphaned lists no context references — pre-existing, and untangling them means new itemData entries and resolving the shadowing against types.

[prql-bot]

Problem

#6207 brought the two Handlebars/highlight.js keyword lists in line with the lexer's keyword parser, but the same drift remains in the grammars this repo ships. Against the ten keywords the lexer defines (let, into, case, prql, type, module, internal, func, import, enum):

Grammar	Missing
web/playground/src/workbench/prql-syntax.js (Monarch)	into, type, module, internal, func, import, enum
grammars/GtkSourceView/prql.lang	into, case, type, module, internal, func, import, enum
grammars/CotEditor/PRQL.yaml	into, type, internal, func, import, enum
grammars/KSyntaxHighlighting/prql.xml	into, case, internal, func, import, enum

The playground one is the most visible: module, type and into render as plain identifiers on prql-lang.org today. The emacs and nano grammars already carry the full set, so they're untouched.

Solution

Add the missing entries to each keyword list, with the same "keep in sync with the lexer" comment #6207 added, so the next drift is easier to spot.

Two grammars also needed their styling adjusting so the added keywords actually render as keywords:

• GtkSourceView had a single declarations context (style-ref="declaration", which maps to def:type), so func/case/into/import would have rendered in the same colour as int and timestamp, while the file's keyword style — mapping to def:keyword — was declared but referenced by nothing. That context is now keywords, styled keyword, holding all ten; the unused declaration style is dropped. prql moves out of built-in-object into it, which brings the file in line with emacs (prql-other-keywords → font-lock-keyword-face), nano and KSyntaxHighlighting, all of which put the same ten on one keyword face.
• KSyntaxHighlighting holds prql in a modules_builtin list that no context references, so it wasn't highlighted at all; it's now in the new keywords list, alongside import in imports. Both map to the same Keyword attribute as the lists beside them. The <language>version is bumped 0 → 1, per KDE's contributing note ("If you are modifying an existing syntax definition XML file, you must increase the version number of the language").

CotEditor and the playground keep their existing groupings — both already carried prql on a keyword list.

Testing

No automated coverage exists for these grammars (#2052 tracks that), so verification is structural: both XML files parse, every style the GtkSourceView file declares is now referenced by a context, the CotEditor YAML parses to the expected 20-entry keyword list, and prettier passes on the JS and YAML.

Found during the nightly rolling survey of grammars/GtkSourceView/prql.lang and web/playground/src/workbench/monaco-theme.json.

[prql-bot]

Two observations on the grammar files, one of which means the PR doesn't quite reach its own goal.

prql still isn't highlighted in the KSyntaxHighlighting grammar. The new comment says "prql is a built-in module", but the modules_builtin list holding it isn't referenced by any context — the only keyword rules in the Normal context are types, specialvars, builtinfuncs, declarations, letExpressions, imports and the newly-added keywords (date_functions, text_functions and durations are orphaned the same way). So prql renders as a plain identifier in Kate, and the comment points the next person checking for drift at a list that does nothing. The inline suggestion adds it to the new keywords list; the alternative — referencing modules_builtin from Normal — needs a new itemData and would be shadowed for date/text, which the types rule already claims a few lines earlier.

In GtkSourceView all nine land on style-ref="declaration", which maps to def:type.func, case, into and import will render in the same colour as int and timestamp, while the file declares <style id="keyword" … map-to="def:keyword"/> that nothing references (grep style-ref= prql.lang returns every style except keyword). The other three grammars here put these tokens on a keyword token/attribute, and emacs' prql-other-keywords — the same ten — uses font-lock-keyword-face. A second context styled keyword, mirroring the new keywords list this PR adds on the KSyntaxHighlighting side, would be more consistent; whether let/type/module move with it is a styling call, so leaving it rather than pushing one.

Two smaller things:

• prql.xml still carries version="0", unchanged since the file was added, and this is the first content change to it. I believe KSyntaxHighlighting selects among duplicate definitions of a language by that attribute, so it's conventionally incremented on each edit — I couldn't reach docs.kde.org from CI to confirm the exact rule, hence flagging rather than suggesting.
• Four grammars drifted simultaneously here. The sync comments make the next drift easier to spot but nothing fails when it happens, and test-grammars only covers lezer and raku. keyword() spells its ten out inline; lifting them into a const would let a small test assert each grammar file mentions each keyword — cheap coverage for the part of #2052 that bit here.

[prql-bot]

Thanks — both grammar points were real; pushed 2e54e6a and 9ebdbf3.

GtkSourceView styling. Made the call and moved all ten onto keyword: the declarations context is now keywords, style-ref="keyword", the unreferenced declaration style is dropped, and prql moves out of built-in-object into it. That matches emacs (prql-other-keywords → font-lock-keyword-face), nano (one color yellow line for the same ten) and KSyntaxHighlighting (every keyword list → the Keyword attribute), so all five grammars now put the lexer's keywords on one face. Every style the file declares is referenced by a context again, which is what flagged the problem in the first place.

version="0". Confirmed and bumped to 1 — KDE's contributing notes say "If you are modifying an existing syntax definition XML file, you must increase the version number of the language." (docs.kde.org is unreachable from CI, but the repo README is fetchable via the API.)

A drift test. Agreed it's the right fix for the class of bug, but it's independently revertable from this PR and I'm at five open PRs, so noting the shape here rather than opening a sixth: lift the ten just(..) arms in keyword() into a pub const KEYWORDS: [&str; 10], drive the parser from it, and assert in a test that each grammar file under grammars/ carrying a keyword list, plus web/playground/src/workbench/prql-syntax.js, contains every entry. A substring check over the file text is crude but is exactly the assertion that would have failed here, and it needs no per-format parser. #2052 is the tracking issue.

Not addressed: modules_builtin, date_functions, text_functions and durations in prql.xml are all orphaned lists no context references — pre-existing, and untangling them means new itemData entries and resolving the shadowing against types.

[prql-bot]

Problem

#6207 brought the two Handlebars/highlight.js keyword lists in line with the lexer's keyword parser, but the same drift remains in the grammars this repo ships. Against the ten keywords the lexer defines (let, into, case, prql, type, module, internal, func, import, enum):

Grammar	Missing
web/playground/src/workbench/prql-syntax.js (Monarch)	into, type, module, internal, func, import, enum
grammars/GtkSourceView/prql.lang	into, case, type, module, internal, func, import, enum
grammars/CotEditor/PRQL.yaml	into, type, internal, func, import, enum
grammars/KSyntaxHighlighting/prql.xml	into, case, internal, func, import, enum

The playground one is the most visible: module, type and into render as plain identifiers on prql-lang.org today. The emacs and nano grammars already carry the full set, so they're untouched.

Solution

Add the missing entries to each keyword list, with the same "keep in sync with the lexer" comment #6207 added, so the next drift is easier to spot.

Two grammars also needed their styling adjusting so the added keywords actually render as keywords:

• GtkSourceView had a single declarations context (style-ref="declaration", which maps to def:type), so func/case/into/import would have rendered in the same colour as int and timestamp, while the file's keyword style — mapping to def:keyword — was declared but referenced by nothing. That context is now keywords, styled keyword, holding all ten; the unused declaration style is dropped. prql moves out of built-in-object into it, which brings the file in line with emacs (prql-other-keywords → font-lock-keyword-face), nano and KSyntaxHighlighting, all of which put the same ten on one keyword face.
• KSyntaxHighlighting holds prql in a modules_builtin list that no context references, so it wasn't highlighted at all; it's now in the new keywords list, alongside import in imports. Both map to the same Keyword attribute as the lists beside them. The <language>version is bumped 0 → 1, per KDE's contributing note ("If you are modifying an existing syntax definition XML file, you must increase the version number of the language").

CotEditor and the playground keep their existing groupings — both already carried prql on a keyword list.

Testing

No automated coverage exists for these grammars (#2052 tracks that), so verification is structural: both XML files parse, every style the GtkSourceView file declares is now referenced by a context, the CotEditor YAML parses to the expected 20-entry keyword list, and prettier passes on the JS and YAML.

Found during the nightly rolling survey of grammars/GtkSourceView/prql.lang and web/playground/src/workbench/monaco-theme.json.

[prql-bot]

Two observations on the grammar files, one of which means the PR doesn't quite reach its own goal.

prql still isn't highlighted in the KSyntaxHighlighting grammar. The new comment says "prql is a built-in module", but the modules_builtin list holding it isn't referenced by any context — the only keyword rules in the Normal context are types, specialvars, builtinfuncs, declarations, letExpressions, imports and the newly-added keywords (date_functions, text_functions and durations are orphaned the same way). So prql renders as a plain identifier in Kate, and the comment points the next person checking for drift at a list that does nothing. The inline suggestion adds it to the new keywords list; the alternative — referencing modules_builtin from Normal — needs a new itemData and would be shadowed for date/text, which the types rule already claims a few lines earlier.

In GtkSourceView all nine land on style-ref="declaration", which maps to def:type.func, case, into and import will render in the same colour as int and timestamp, while the file declares <style id="keyword" … map-to="def:keyword"/> that nothing references (grep style-ref= prql.lang returns every style except keyword). The other three grammars here put these tokens on a keyword token/attribute, and emacs' prql-other-keywords — the same ten — uses font-lock-keyword-face. A second context styled keyword, mirroring the new keywords list this PR adds on the KSyntaxHighlighting side, would be more consistent; whether let/type/module move with it is a styling call, so leaving it rather than pushing one.

Two smaller things:

• prql.xml still carries version="0", unchanged since the file was added, and this is the first content change to it. I believe KSyntaxHighlighting selects among duplicate definitions of a language by that attribute, so it's conventionally incremented on each edit — I couldn't reach docs.kde.org from CI to confirm the exact rule, hence flagging rather than suggesting.
• Four grammars drifted simultaneously here. The sync comments make the next drift easier to spot but nothing fails when it happens, and test-grammars only covers lezer and raku. keyword() spells its ten out inline; lifting them into a const would let a small test assert each grammar file mentions each keyword — cheap coverage for the part of #2052 that bit here.

[prql-bot]

Thanks — both grammar points were real; pushed 2e54e6a and 9ebdbf3.

GtkSourceView styling. Made the call and moved all ten onto keyword: the declarations context is now keywords, style-ref="keyword", the unreferenced declaration style is dropped, and prql moves out of built-in-object into it. That matches emacs (prql-other-keywords → font-lock-keyword-face), nano (one color yellow line for the same ten) and KSyntaxHighlighting (every keyword list → the Keyword attribute), so all five grammars now put the lexer's keywords on one face. Every style the file declares is referenced by a context again, which is what flagged the problem in the first place.

version="0". Confirmed and bumped to 1 — KDE's contributing notes say "If you are modifying an existing syntax definition XML file, you must increase the version number of the language." (docs.kde.org is unreachable from CI, but the repo README is fetchable via the API.)

A drift test. Agreed it's the right fix for the class of bug, but it's independently revertable from this PR and I'm at five open PRs, so noting the shape here rather than opening a sixth: lift the ten just(..) arms in keyword() into a pub const KEYWORDS: [&str; 10], drive the parser from it, and assert in a test that each grammar file under grammars/ carrying a keyword list, plus web/playground/src/workbench/prql-syntax.js, contains every entry. A substring check over the file text is crude but is exactly the assertion that would have failed here, and it needs no per-format parser. #2052 is the tracking issue.

Not addressed: modules_builtin, date_functions, text_functions and durations in prql.xml are all orphaned lists no context references — pre-existing, and untangling them means new itemData entries and resolving the shadowing against types.

[prql-bot]

Problem

#6207 brought the two Handlebars/highlight.js keyword lists in line with the lexer's keyword parser, but the same drift remains in the grammars this repo ships. Against the ten keywords the lexer defines (let, into, case, prql, type, module, internal, func, import, enum):

Grammar	Missing
web/playground/src/workbench/prql-syntax.js (Monarch)	into, type, module, internal, func, import, enum
grammars/GtkSourceView/prql.lang	into, case, type, module, internal, func, import, enum
grammars/CotEditor/PRQL.yaml	into, type, internal, func, import, enum
grammars/KSyntaxHighlighting/prql.xml	into, case, internal, func, import, enum

The playground one is the most visible: module, type and into render as plain identifiers on prql-lang.org today. The emacs and nano grammars already carry the full set, so they're untouched.

Solution

Add the missing entries to each keyword list, with the same "keep in sync with the lexer" comment #6207 added, so the next drift is easier to spot.

Two grammars also needed their styling adjusting so the added keywords actually render as keywords:

• GtkSourceView had a single declarations context (style-ref="declaration", which maps to def:type), so func/case/into/import would have rendered in the same colour as int and timestamp, while the file's keyword style — mapping to def:keyword — was declared but referenced by nothing. That context is now keywords, styled keyword, holding all ten; the unused declaration style is dropped. prql moves out of built-in-object into it, which brings the file in line with emacs (prql-other-keywords → font-lock-keyword-face), nano and KSyntaxHighlighting, all of which put the same ten on one keyword face.
• KSyntaxHighlighting holds prql in a modules_builtin list that no context references, so it wasn't highlighted at all; it's now in the new keywords list, alongside import in imports. Both map to the same Keyword attribute as the lists beside them. The <language>version is bumped 0 → 1, per KDE's contributing note ("If you are modifying an existing syntax definition XML file, you must increase the version number of the language").

CotEditor and the playground keep their existing groupings — both already carried prql on a keyword list.

Testing

No automated coverage exists for these grammars (#2052 tracks that), so verification is structural: both XML files parse, every style the GtkSourceView file declares is now referenced by a context, the CotEditor YAML parses to the expected 20-entry keyword list, and prettier passes on the JS and YAML.

Found during the nightly rolling survey of grammars/GtkSourceView/prql.lang and web/playground/src/workbench/monaco-theme.json.

[prql-bot]

Two observations on the grammar files, one of which means the PR doesn't quite reach its own goal.

prql still isn't highlighted in the KSyntaxHighlighting grammar. The new comment says "prql is a built-in module", but the modules_builtin list holding it isn't referenced by any context — the only keyword rules in the Normal context are types, specialvars, builtinfuncs, declarations, letExpressions, imports and the newly-added keywords (date_functions, text_functions and durations are orphaned the same way). So prql renders as a plain identifier in Kate, and the comment points the next person checking for drift at a list that does nothing. The inline suggestion adds it to the new keywords list; the alternative — referencing modules_builtin from Normal — needs a new itemData and would be shadowed for date/text, which the types rule already claims a few lines earlier.

In GtkSourceView all nine land on style-ref="declaration", which maps to def:type.func, case, into and import will render in the same colour as int and timestamp, while the file declares <style id="keyword" … map-to="def:keyword"/> that nothing references (grep style-ref= prql.lang returns every style except keyword). The other three grammars here put these tokens on a keyword token/attribute, and emacs' prql-other-keywords — the same ten — uses font-lock-keyword-face. A second context styled keyword, mirroring the new keywords list this PR adds on the KSyntaxHighlighting side, would be more consistent; whether let/type/module move with it is a styling call, so leaving it rather than pushing one.

Two smaller things:

• prql.xml still carries version="0", unchanged since the file was added, and this is the first content change to it. I believe KSyntaxHighlighting selects among duplicate definitions of a language by that attribute, so it's conventionally incremented on each edit — I couldn't reach docs.kde.org from CI to confirm the exact rule, hence flagging rather than suggesting.
• Four grammars drifted simultaneously here. The sync comments make the next drift easier to spot but nothing fails when it happens, and test-grammars only covers lezer and raku. keyword() spells its ten out inline; lifting them into a const would let a small test assert each grammar file mentions each keyword — cheap coverage for the part of #2052 that bit here.

[prql-bot]

Thanks — both grammar points were real; pushed 2e54e6a and 9ebdbf3.

GtkSourceView styling. Made the call and moved all ten onto keyword: the declarations context is now keywords, style-ref="keyword", the unreferenced declaration style is dropped, and prql moves out of built-in-object into it. That matches emacs (prql-other-keywords → font-lock-keyword-face), nano (one color yellow line for the same ten) and KSyntaxHighlighting (every keyword list → the Keyword attribute), so all five grammars now put the lexer's keywords on one face. Every style the file declares is referenced by a context again, which is what flagged the problem in the first place.

version="0". Confirmed and bumped to 1 — KDE's contributing notes say "If you are modifying an existing syntax definition XML file, you must increase the version number of the language." (docs.kde.org is unreachable from CI, but the repo README is fetchable via the API.)

A drift test. Agreed it's the right fix for the class of bug, but it's independently revertable from this PR and I'm at five open PRs, so noting the shape here rather than opening a sixth: lift the ten just(..) arms in keyword() into a pub const KEYWORDS: [&str; 10], drive the parser from it, and assert in a test that each grammar file under grammars/ carrying a keyword list, plus web/playground/src/workbench/prql-syntax.js, contains every entry. A substring check over the file text is crude but is exactly the assertion that would have failed here, and it needs no per-format parser. #2052 is the tracking issue.

Not addressed: modules_builtin, date_functions, text_functions and durations in prql.xml are all orphaned lists no context references — pre-existing, and untangling them means new itemData entries and resolving the shadowing against types.