Array-variables are highlighted as function

[jwortmann]

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. to variable.other.fortran, to minimize the number of incorrectly highlighted identifiers.

One exception to this, where variable.function can be used correctly is after the call keyword for subroutine calls.

Another thing I noticed is that built-in functions and subroutines use variable.function.function.intrinsic.fortran and variable.function.subroutine.intrinsic.fortran. I would suggest to use something like support.function.intrinsic.fortran and support.function.subroutine.fortran for these instead, because support.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.

[eirik-kjonstad]

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.

[jwortmann]

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 sublimehq/Packages#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.