Highlighting fails in long and messy fortran files

[vkbo]

I work with a few old and very messy fortran77 physics codes, and they tend to "loose track" when syntax highlighting. Usually everything ends up being the default colour for variables.

See for instance this file: https://github.com/Jadzia626/SixTrack/blob/master/SixTrack/sixtrack.s

I'm using fixed form. I'm not sure whether this is Atom failing or the language pack.

[vkbo]

There is a bug in the code there that fails to close a parenthesis correctly (line 27465). Seems to be the cause. However highlighting should recover from this. Other editors seem to do. Again, not sure whether this is the language plugin or atom.

[tomedunn]

Thanks, for posting! I know where the source of the problem stems from. It has to do with the rule for the parentheses attached to the sqrt function which is looking for a closed bracket in order to terminate. In older versions of the package, it would also terminate when it reached the end of a line (assuming no line continuation statement was present), however this was changed to allow the rules to be applied more generally to both fixed and free form files, since fixed form allows a line continuation marker to appear on the line after the line being continued.

So this behavior is semi-intentional to allow parentheses to span multiple lines in fixed form source files. However, it could be useful if the rules also looked for clear signs that something has gone wrong, e.g., the start of an if statement or some other statement than can't exist inside of a set of parentheses, to avoid scenarios where an unmatched parentheses consumes the entire file. I'll see what I can do when I have some free time this week. In the mean time, make sure those parentheses are closed! 😄

[vkbo]

The problem is of course really that breaking lines across compiler pre-processor blocks is messy. (The +if lines are for a custom written pre-processor for this code.) The code compiles just fine as the two blocks are mutually exclusive so the code is technically correct. I just submitted a patch to fix this in our source, so highlighting works again for me now. But it would be great if the syntax highlighting could manage such cases. It seems to work fine in for instance Geany and Emacs. Not sure what logic these editors apply to this case.

Anyway, good to see someone made the fortran package for atom. I'm not at all surprised that the repository is owned by an astrophysicist!

[tomedunn]

I'm not familiar with either Geany or Emacs syntax highlighting engines, but I can at least attest to the fact that the Atom syntax engine (which is derived from the Textmate and Sublime Text engines) isn't particularly well suited for how the Fortran language is structured. A large portion of the problem comes from the source code being broken up into lines before being processed for syntax highlighting. Fortran has a number of features that can span multiple lines and sometimes you have to be able to look ahead to the next line in order to accurately highlight the line you are on. Unfortunately doing so isn't possible in Atom. In order to extend highlighting to be as accurate as it can be given these limitations, this package has expanded to cover much more of the source than most other syntax packages (almost everything in a Fortran source file is assigned a scope as opposed to only assigning scopes to things like keywords, constants, and function names). The down side of doing it this way is that it makes things more fragile to deviations.