syntax: gleam: add highlighting for .gleam #3374
Conversation
runtime/syntax/gleam.yaml
Outdated
| - symbol: "(\\.\\.|\\.|,|:)" | ||
| - symbol.brackets: "({|}|\\(|\\)|\\[|\\]|<<|>>)" | ||
| - symbol.operator: "(^\\s+\\|>|<>|<-|->|\\+\\.|\\-\\.|/\\.|\\*\\.|%\\.|\\+|\\-|/|\\*|%|=)" | ||
| - constant.number: "\\b(0[bBoOxX][a-fA-F0-9][a-fA-F0-9_\\.]*|[0-9][0-9_\\.]*)\\b" |
There was a problem hiding this comment.
This can be made more precise: binary, octal, and hexadecimal literals can't have . in them, and Gleam also supports scientific notation for floats (https://tour.gleam.run/basics/number-formats/). Trailing underscore is not valid.
| - constant.number: "\\b(0[bBoOxX][a-fA-F0-9][a-fA-F0-9_\\.]*|[0-9][0-9_\\.]*)\\b" | |
| - constant.number: "\\b[0-9](_?[0-9]+)*(\\.([0-9](_?[0-9]+)*)?(e-?[0-9]+)?)?\\b" | |
| - constant.number: "\\b0([bB][01](_?[01]+)*|[oO][0-7](_?[0-7]+)*|[xX][0-9A-Fa-f](_?[0-9A-Fa-f]+)*)\\b" |
| # bit arrays | ||
| - special: | ||
| start: "<<" | ||
| end: ">>" | ||
| rules: [] |
There was a problem hiding this comment.
You could add highlighting for the bit array options under rules here (https://tour.gleam.run/data-types/bit-arrays/)
There was a problem hiding this comment.
I actually thought it might be clearer as is, making them look similar to strings, due to their special syntax. I took an initial stab, but a bug in the regex helps make a comparison. Here, I have no idea what makes :size(16) not match :(size|unit|bits|bytes|float|int|big|little|native|utf8|utf16|utf32|utf8_codepoint|utf16_codepoint|utf32_codepoint|signed|unsigned)(\\([0-9]+\\))?, but I actually think having the entire bit array highlighted similar to a string makes it read easier...
| - symbol.brackets: "({|}|\\(|\\)|\\[|\\]|<<|>>)" | ||
| - symbol.operator: "(^\\s+\\|>|<>|<-|->|\\+\\.|\\-\\.|/\\.|\\*\\.|%\\.|\\+|\\-|/|\\*|%|=)" | ||
| - constant.number: "\\b(0[bBoOxX][a-fA-F0-9][a-fA-F0-9_\\.]*|[0-9][0-9_\\.]*)\\b" | ||
| - constant.bool: "\\s(<|>|<\\.|>\\.|<=|>=|<=\\.|>=\\.|==|!=|==\\.|&&|\\|\\||\\|)\\s" |
There was a problem hiding this comment.
These are operators, not constants. There's also some overlap with symbol.operator defined above. I don't think the whitespace before and after is required because this seems to work:
io.debug(True&&False)There was a problem hiding this comment.
Agreed, ideally there would be an symbol.operator.bool option to support the highlighting logic below, which I find helpful. I understand if it's too idiosyncratic for a default, though. Will fix the whitespace issue.
There was a problem hiding this comment.
I wasn't able to remove the whitespace without clashing with the other operators... I'm afraid it's a bit brittle, but it does well with real code, at least using my color scheme.
There was a problem hiding this comment.
Agreed, ideally there would be an
symbol.operator.booloption to support the highlighting logic below, which I find helpful. I understand if it's too idiosyncratic for a default, though.
The way the highlighting works if you have symbol.operator.bool it will first look for symbol.operator.bool, then symbol.operator, and finally symbol in the current colorscheme. So that should just work, although you would need to use a customized colorscheme to see the difference.
I wasn't able to remove the whitespace without clashing with the other operators... I'm afraid it's a bit brittle, but it does well with real code, at least using my color scheme.
You can usually work around the clashes by reordering the definitions (if I recall correctly the later ones take precedence). Although it's not much of an issue in practice because almost all colorschemes use the same color for the two different kinds of operators anyway.
|
|
||
| rules: | ||
| - identifier: "\\b[a-z][a-z0-9_]*\\b" | ||
| - ignore: "(\\b(_[a-z][a-z0-9_]*)\\b|\\b(auto|delegate|derive|echo|else|implement|macro|test)\\b)" |
There was a problem hiding this comment.
Are these reserved but unimplemented keywords? I can't find a reference for them online.
There was a problem hiding this comment.
Yes, the ignore line is meant to cover ignored (preceded by _) and reserved words. I found the latter here, under "Language additions", and also noticed a few existing Gleam syntax definitions included them.
Tested against: https://learnxinyminutes.com/docs/files/learngleam.gleam