Closed ahelm closed 7 years ago
Thanks for posting. Unfortunately, I think this is more likely a bug in the syntax theme you're using than this language package.
To explain, how a color scheme interacts with a language package falls pretty much entirely on the color scheme side of the equation as long as the syntax package is following the standard textmate scoping convention, as is the case with language-fortran. I ran a simple test to check that there wasn't something wrong with the scoping
In both cases the scoping for =
is keyword.operator.assignment
. The trailing .c
and .fortran
should have no impact on the way the color scheme is applied and neither should the meta
or source
scopes. So the fact that =
is colored differently in both examples points to there being something different in how the "One Dark" theme is being applied to the two different language, which really shouldn't be the case.
The other main difference between these two cases is how some_variable
is scoped by this syntax and the C syntax. In the C syntax some_variable
is not given any scope while for the Fortran syntax it is given the meta.variable
scope. All scopes that start with meta
shouldn't be assigned a color. So again, it looks like the "One Dark" theme is doing something strange with their color assignments.
The main theme that I use when testing language-fortran is the "Monokai Seti" theme, shown below
As you can see the color assignment is much more consistent. The only remaining difference is between the name of the program unit in Fortran and the name of the function unit in C, which is to expected since they are intentionally scoped differently. A fairer comparison would be with a function or subroutine in Fortran as shown below
Interesting. I tried different syntax schemes and found basically out that, as you said, it depends on the scoping convention and with the default themes it seems to have different conventions each time as it didn't had a consistency.
Thanks for the clarification.
language-fortran is a bit more ambitious than most other languages in that it assigns scopes to nearly every element in any given file. However, most of those additional scoped elements are given scopes that shouldn't be highlighted (such as those using the meta
scope). The fact that so many of the default color schemes seem to actually apply some kind of color, or other emphasis, is a bit concerning. If there's been a move to extend highlighting to scopes beyond the standard Textmate scopes it would be good to know that.
One issue I discovered recently is quite striking. The issue is, that for most color schemes in Atom, the color scheme for fortran files looks really unsatisfying while for other languages it provides a pleasing highlighting.
For example, let's compare some Fortran code
and some C code
I am using here the "One Dark" color scheme with Atom 1.19.2. Other schemes have showed similar issues. The issue is that some syntax pieces has a different color and making it less appealing for the eye and less consistency throughout the editor, e.g. variables are highlighted and should not have any highlight. It arises due to the fact, that every syntax matching has it own class and for simple variables a color is applied as Atom assumes that it has specific significance.
Is it possible to modify the matching of the syntax that the syntax schemes get better aware of specific highlighting? I can modify my local
styles.less
to match specific classes to be not highlighted how they are, but I think a general approach would be helpful and helpful for other users as well. I can also make a pull request and change things, if you wish, but I would appreciate to have your take on that.