Open jwortmann opened 3 years ago
We decided to use variable.function.fortran
instead of variable.other.fortran
, but you may be right that this is not the better choice for most developers. In my experience, function calls will dominate high-level code, where much of the code consists of calls to functions and subroutines. Array access will be more common in low-level code. What you encounter more often will depend on the code (or what part of a larger codebase) you are working on. Do you have any thoughts on this @saraidery ?
If these scopes are typically used for built-in functions, I think we can follow the convention. I see that the Python syntax is also using support.function
for its built-in functions. Your suggestions seem good to me - I can make a pull request soon.
If these scopes are typically used for built-in functions, I think we can follow the convention. I see that the Python syntax is also using support.function for its built-in functions. Your suggestions seem good to me - I can make a pull request soon.
In general support.function
should be used for built-in or standard library functions, while variable.function
is meant to be used for user-defined function calls.
I noticed that you also used support.function
for C preprocessor statements and for OpenMP statements, and I could imagine that you perhaps chose this scope name because it gives a (for now) unique color in most color schemes. There are some smaller deviations in the built-in syntaxes for preprocessor statements and there was some not yet resolved discussion in https://github.com/sublimehq/Packages/issues/1860, but the preprocessor keywords should probably use keyword
instead; for example meta.preprocessor.fortran keyword.control.directive.fortran
. And I would suggest to use a similar scope for OpenMP statements as well, perhaps meta.openmp.fortran keyword.control.directive.fortran
here.
If a unique color for these is desired, the correct way would be to create a user-specific override for the color scheme.
This syntax uses
variable.function.fortran
for identifiers preceding an opening parenthesis. This works fine for function and subroutine calls, but at the same time all array-variables are falsely highlighted as a function.In general there is no way with a regex-based highlighting engine to distinguish between array access and a function call in Fortran. The built-in Matlab syntax in Sublime Text suffers from the same issue, and it uses the scope
meta.variable.other.valid.matlab
for all identifiers. And the (abandoned?) Fortran package from Package Control uses only a meta scope for such identifiers as well.From personal experience I would say that array-variables occur much more often in code than function calls, so I would suggest to not use the
variable.function
scope for identifiers, but change it e.g. tovariable.other.fortran
, to minimize the number of incorrectly highlighted identifiers.One exception to this, where
variable.function
can be used correctly is after thecall
keyword for subroutine calls.Another thing I noticed is that built-in functions and subroutines use
variable.function.function.intrinsic.fortran
andvariable.function.subroutine.intrinsic.fortran
. I would suggest to use something likesupport.function.intrinsic.fortran
andsupport.function.subroutine.fortran
for these instead, becausesupport.function
is the usually used scope name for built-in functions and this way they get highlighted differently from user-defined functions (subroutines) by default in most color schemes.