[mst-mkt]

Issue

resolve #236

Summary

This PR fixes an issue where a bare (unquoted) string used as a record value was highlighted as a command name, causing every subsequent key to lose its key color.
The record key rules in repository.braced-expression now open a region that covers the value, so the value is scanned as a value instead of falling through to the command rule.

Background Information

• The key rules were previously match rules covering only key:. The value fell through to {"include": "source.nushell"} and was picked up by the command rule, whose region ends at (?=\||\)|\}|;)|$ — causing it to run all the way to the closing } and swallow the remaining keys as string.bare.nushell.
• The region now ends at (?=[,}])|(?<=[^\s:])(?=\s). Since record entries can be separated by commas, spaces, or newlines, a whitespace boundary must also close the entry. The lookbehind keeps the entry open as long as only the colon has been seen, which allows a value to sit on the line after the colon.
• #record-value is #value without #control-keywords and #operators. A record value is a value, not an expression: Nushell rejects {a: 1 + 2} and interprets {a: if} as the string "if". #ranges is kept for {a: 1..5}, and #spread must precede it; otherwise, {a: ...$b} would be split into .. and .$b.
• The bare key pattern accepts what Nushell accepts: anything except whitespace, :, ,, |, ;, (, ), {, }, ", and ', with $ or # disallowed as the first character. The pattern also carries a negative lookahead for ISO datetimes, because without it the class would start at the same offset as #datetime and win the tie, splitting 2024-01-01T00:00:00Z inside blocks and closures.
• Bare keys are scoped string.bare.nushell variable.other.nushell for the same reason as Syntax highlighting broken for record keys containing brackets #231: a token whose standard type is Other has its brackets recognized by bracket pair colorization, which would otherwise show ] in { a]b: 1 } as unmatched.

Verification

I compared the scope of every token before and after the change using vscode-textmate, ignoring the newly added meta.record-entry.nushell ancestor.

• example.nu: 22 lines are tokenized differently, all of which correspond to the reported defect.
• npm run test:grammar passes without regenerating the snapshot.
• Loaded the extension locally in VS Code to confirm the colors.

Known Issue

When a comment is placed between the key and a value on a subsequent line, the value is still highlighted as a command:

{
  a:
  # note
  foo
}

The comment is consumed inside the entry, causing the lookbehind to see its last character and close the entry prematurely. Since main mis-scopes this case as well, this is not a regression.

[fdncred]

Thanks!