eirik-kjonstad/modern-fortran-syntax

Modern Fortran syntax highlighting for Sublime Text 3/4

modern-fortran-syntax's Issues

Several tests fail in development branch

Probably due to failure of git-automerge in most recent merge where parenthesis-scopes were introduced.

Will have a look at it tomorrow.

Typing "use..." gives incorrect coloring on lines that follow

use myModule
!
implicit none

looks ok, but

use
!
implicit none 

does not recognize ! nor implicit none correctly.

Variable declarations only recognize initial type keyword (e.g. real) when :: is reached

When typing incomplete statements of the type

real(8), dimension(:,:), allocatable :: myArray

the syntax recognizes "real" correctly when :: is reached but not before that point is reached.

This can lead to some annoying color changes in many color schemes.

Improvements to "implicit ..."

The syntax currently only recognizes "implicit none" and should be expanded to handle other syntax that begins with "implicit".

Functions are in some cases incorrectly scoped as objects

I've noticed that the syntax will sometimes incorrectly scope expressions involving functions and object-accessing. Here is an example:

result = foo(object%member)    ! foo scoped as variable.function
result = foo(object(k)%member) ! foo scoped as storage.type.class

The reason for the wrong scope is the following:

    - match: '(\w+)\s*(?=\%|\[.*\]\(.*\)\%|\(.*\)\%|\[.*\]\%)'
      scope: storage.type.class.fortran

It assumes that the ) in object(k) is the closing parenthesis of foo and so misinterprets foo as an storage.type.class.

Duplicate entries in the symbol list

If a function or subroutine name is repeated after the end function/subroutine statement, it will create a duplicate entry in the symbol list for this function/subroutine name. This happens because the identifier uses the scope entity.name.function in both cases, which will automatically added to the symbol list by default. But it only makes sense to have a single entry (pointing to the definition line) for the "Goto Symbol" functionality.

Example:

function foo(x,y,z)
  ...
end function foo

If the same highlighting color for both occurences of the identifier should be kept, one of it could be adjusted to use for example an additional meta scope, and the one after end could be excluded from the symbol list via a .tmPreferences file then.

I think I could prepare a PR to fix this (I guess I would add proper meta scopes to the function/subroutine definition line in that case).

Single "end" should be keyword

A single end is currently highlighted as variable.language.io.fortran, which is a bit annoying because it changes its color in many color schemes while typing.

I think it might be better from a highlighting perspective to include a rule like

- match: \bend\b
  scope: keyword.control.end.fortran

somewhere appropriate to always highlight end as keyword. Or maybe use e.g. the scope keyword.declaration.end.fortran instead.

fypp syntax highlighting support

Would it be possible to add support for fypp (https://fypp.readthedocs.io/en/stable/fypp.html)?

I imagine two modes, one where fypp directives (lines beginning with #, $ or @) are highlighted as comments, and a second mode which would add coloring also to the preprocessor directives. Which mode to use could be set in a JSON settings file of the package.

As a side note, what are the advantages/differences of this package compared to the older https://packagecontrol.io/packages/Fortran? I've been using the previous one, but after re-installing Sublime thought I'd give this package a go instead.

Also perhaps of interest, @cdslaborg has published a list of Fortran keywords in response to a thread at Fortran Discourse. These can be useful to cross-check for syntax highlighting.

variables and functions have the same colour

In all color schemes I use variables and functions have the same color. This is extremly confusing. It would be natural that variables have no special colour.

block/end block (and associate/end associate)

I've just tried out modern-fortran-syntax for use in bat. It's very nice, I like it!

I found a couple of constructs which are not present.
Unfortunately I don't know the format for defining syntax, so I don't think I can offer a PR.

Fortran (2008, I think) added the scoping construct block/end block [1] (Some examples: https://stackoverflow.com/a/51476018)

block
...
end block

Also the associate/end associate construct [2]. This looks like:

associate(a => b)
...
end associate

Some examples of both are in the example:
https://github.com/hattom/derived_reduction/blob/main/test_reduce.F90

[1] In the 202X draft document I have from Dec 2020 (J3/21-007), it's detailed in 11.1.4.
[2] 11.1.3 in [1]

Array-variables are highlighted as function

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.

Import statement not recognized

For example

import :: myClass