You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adding a space after the colon in the following pattern in jsonnet-font-lock-keywords-1 seems to fix this, but not 100% sure if this would break anything else.
It seems the original intent of this regular expression was to match object keys that are also identifiers (i.e. not strings). If that's the case, this is just a bad way to match those cases. Having a look at Jsonnet's specification, it seems this is perhaps an inappropriate use for font-lock-keyword-face which should instead be reserved for real keywords, e.g. assert, else, etc. I was hoping to avoid another regex problem but it seems font-lock-builtin-face is already used for those cases. Like #31, this would be much more nicely solved with tree-sitter, but I assume that's a whole lot of work (at least as involved as converting indentation to SMIE [q.v. #17]).
For example, in
a
will not be highlighted.Adding a space after the colon in the following pattern in
jsonnet-font-lock-keywords-1
seems to fix this, but not 100% sure if this would break anything else.Edit: actually since
{ a:'b:c' }
is valid jsonnet, adding a space after the colon in the pattern wouldn't be a great solution :(The text was updated successfully, but these errors were encountered: