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
I like the functionality of this extension a lot. However, it chooses syntax colors that aren't what I would expect.
I would expect strings in an EBNF specification to appear in the same color as constant strings in code, e.g. in a Python program. In my Visual Studio theme (Light Modern), this is red. But with this extension strings appear black.
This extension colors a non-terminal that's being defined (on the left side of '=') in the same color that Visual Studio uses for keywords in programming languages. In the Light Modern theme this is blue. That seems wrong to me, since a non-terminal is not a keyword. In my opinion, a non-terminal that's being defined should have the same color as a non-terminal that's being used (on the right side of '='). By analogy, if I write Python code such as
def foo(x):
return bar(x)
then VS Code displays 'foo' and 'bar' in the same color, even though 'foo' is a function that's being defined and 'bar' is a function that's being called. Simply put, they are both the same kind of thing, i.e. a function, so I think they should have the same color.
I know that these colors are a matter of opinion, so if you disagree you can simply close this. But I thought I would at least bring this up.
The text was updated successfully, but these errors were encountered:
Now that I've used the extension a bit more, I think that having a different color on the left side of the '=' is not so bad, so maybe my second point above is not so important. I still think it would be nicer if strings were colored consistently with source files containing code.
Excellent point @medovina. Thank you for your report.
The intention was indeed to have separate colours between terminal and no-terminal. The problem is that the wrong TextMate scope name "keyword.other.syntax.rule.ebnf" was used for the non-terminal, which is semantically incorrect.
I am working on a fix now:
for non-terminals: replace "keyword.other.syntax.rule.ebnf" with "entity.name.function.rule.ebnf" - semantically correct for definitions.
for terminals: to achieve the colour differentiation replace the "entity.name.function.rule.ebnf" with "variable.other.constant.ebnf" - semantically reasonable for references. Do you agree?
for strings: replace the "constant.string.ebnf" with "string.quoted.single.ebnf" and "string.quoted.double.ebnf".
Visually, with the default VS Code colouring, will look like this:
Do you have any suggestions and/or additions before I apply the fix?
I like the functionality of this extension a lot. However, it chooses syntax colors that aren't what I would expect.
I would expect strings in an EBNF specification to appear in the same color as constant strings in code, e.g. in a Python program. In my Visual Studio theme (Light Modern), this is red. But with this extension strings appear black.
This extension colors a non-terminal that's being defined (on the left side of '=') in the same color that Visual Studio uses for keywords in programming languages. In the Light Modern theme this is blue. That seems wrong to me, since a non-terminal is not a keyword. In my opinion, a non-terminal that's being defined should have the same color as a non-terminal that's being used (on the right side of '='). By analogy, if I write Python code such as
then VS Code displays 'foo' and 'bar' in the same color, even though 'foo' is a function that's being defined and 'bar' is a function that's being called. Simply put, they are both the same kind of thing, i.e. a function, so I think they should have the same color.
I know that these colors are a matter of opinion, so if you disagree you can simply close this. But I thought I would at least bring this up.
The text was updated successfully, but these errors were encountered: