comments like

cxx

xx would make it not to detect as comment.

The 'Fortran - Fixed Form' grammar highlights even after column 72. And the highlight seems to depend on the particular Fortran statement.

I recommend applying the comment highlight to anything after column 72.

Thanks.

Hi,
Good example being better than long sentences:

Source file has extension .f90

Also affects other intrinsics starting with c and likely to appear in first column of the file, like character

Might be related to recent issue #52

Hi there,

Shouldn't i and j (index variables) have the same colour in do and do concurrent() ?

Store package settings files in the settings/ directory instead of scoped-properties/

Package.loadSettings (/usr/share/atom/resources/app.asar/src/package.js:584:9)
<unknown> (/usr/share/atom/resources/app.asar/src/package.js:186:43)
Package.measure (/usr/share/atom/resources/app.asar/src/package.js:165:15)
Package.load (/usr/share/atom/resources/app.asar/src/package.js:179:12)
PackageManager.loadPackage (/usr/share/atom/resources/app.asar/src/package-manager.js:372:14)
PackageManager.loadPackages (/usr/share/atom/resources/app.asar/src/package-manager.js:336:14)

Hello,
It's been a while I'm having trouble with auto-indent in a very long module. I didn't take the time to track back the bug in language-fortran's auto-indent. Here it is! :)

Let's type this in my favorite Atom editor:

program toto
    implicit none
    real :: x
    real :: y ! no problem
    real :: z ! this line contains the word "function" in the comment.
    real :: q ! <= this is sufficient to mess the auto-indent
    real :: messy
end program toto

Now, let's apply Edit > Lines > Auto-Indent ...

program toto
    implicit none
    real :: x
    real :: y ! no problem
    real :: z ! this line contains the word "function" in the comment.
        real :: q ! <= this is sufficient to mess the auto-indent
        real :: messy
    end program toto

Now let's replace function in the declaration of z by anything else and apply again Auto-Indent ...

program toto
    implicit none
    real :: x
    real :: y ! no problem
    real :: z ! this line contains the word "anything else" in the comment.
    real :: q ! <= this is sufficient to mess the auto-indent
    real :: messy
end program toto

Conclusion

When the word function is found in a line, even if it is in a comment, then auto-indent gets wrong.

See the attached image, where the function block is prematurely terminated due the presence of a local variable an_end.

Looking at the match rules in https://github.com/dparkins/language-fortran/blob/master/grammars/fortran%20-%20punchcard.cson, it would seem as if the end rule for the function-definition (and other blocks, program, subroutine, etc.) should include ^\\s* before the capture of (end). For example:

      'end': '(?i)^\\s*(end)(?:\\s*(\\1)(\\s+\\2)?\\b)?\\s*([^;!\\n]+)?'

I notice while working on some other fixes that type attributes defined in Modern Fortran weren't being highlighted in type statements defined in Punchcard Fortran. For example:

"Go to Declaration" does not work

Could you publish this package so that it is downloadable from apm?

Hi, this is more a question than an issue.. I'm new to atom. I have fortran code in files with .F90 and .f90 extension, which have some C preprocessor directives. These look like

define CVAR 1

ifdef CVAR

Some Fortran code...

endif

for example. I see that code between # symbols is left of color white in atom with the language-fortran package.
So, my question is: can we highlight with a particular color (say red) all lines that start with the symbol # (i.e. preprocessor directives) and leave the fortran code inside preprocessor conditionals with its usual colors?

Thank you!

Marcos

A variable called type confused syntax highlighting when assigned from a fucntion call, but not when assign from a literal.

(I discovered with this that type is not a reserved word. Fortran parsing must be so hard ...)

There seems to be an issue with loop indentation. In emacs:

do i = 1, Ntot
    ...
end do

In atom using this package:

do i = 1, Ntot
    ...
    end do 

This seems to be at least for if and do loops. Not sure if it effects anything else.

I'm having some problems with the 'do concurrent' statement
do concurrent (i=1:n)
! code here
end do
the 'concurrent' part has no highlight.

I'm also having problem with the following lines:

interface setGaussLegendre
module procedure setGaussLegendre01, setGaussLegendreAB
end interface setGaussLegendre

I always get a highlighted 'end' inside the 'setGaussLegendre01'.

Thanks!

Atom correctly indents different statements within a module or subroutine as expected. The contain statement is also indented at the level of the procedure it is contained, which I didn't expect but I actually really like:

The issue is, when folding code that contains a contain statement, the folding stops at the contain statement instead of down to where it should fold at end module. This seems to me like atom is repeating some behavior I would expect from python, where everything is progressively nested; however in Fortran that isn't the case.

See gif:

Is it possible to disable the autocompletion of the if statement if it is proceeded by an end? Every time I type end if and hit Enter, it does the following, and then I have to undo.

I have found that if I have a line like this in my code (the third one in the code snippet)

implicit none
integer, parameter :: MAXITER=20,MAXJ=5
dimension g(MAXJ+1)

where the variable g has no assigned type, the atom editor will just hang, and will require a restart. It is very bad coding form, but I would like it if the formatting package didn't crash the editor. Any suggestions?

Hi there, once again : a big thank for all the efforts :), especially to you @tomedunn !

Is this colouring correct?

Modules names should be coloured, shouldn't they?

I've just updated to the latest version of Atom. Now using the fortran bundle when I type sub :

I get this autoinsert into the document:

In following code

do i = 1, 5

end do

do not getting highlighted

Real type declaration statements with a present kind statement are being flagged as the function real().

Hi there :)

Is this coloring expected? Seems strange to me.

I suspect case 1 to be incoherent with the subroutine definitions and so on.

Using an exclamation (!) character to comment code does not highlight the code as comment

Hi there :)

The error stop statement of Fortran 2008 is not detected.
http://fortranwiki.org/fortran/show/Fortran+2008

Thanks again for your time and useful work!

Dummy variable lists in function/subroutine definitions aren't recognizing the line continuation operator &.

This was discussed in issue #57 which is now closed so I wanted to give it it's own issue. To summarize, subroutines called via the call statement are highlighted whether they are intrinsic or not with the exception of type bound subroutines as illustrated below

Frankly I'm not sure if it's possible to make a rule that will correctly highlight these without also highlighting the variable part as well. But for now I'll just leave this issue open as a reminder.

The current rules for do-constructs work perfectly well for standard modern Fortran syntax but there are two use cases missing from the older punchcard Fortran (Fortran 77) standards.

In most cases do-constructs are writen like

do i = 1, 10, 1
  ...
end do

However, one could also replace the enddo statement with a continue statement

do i = 1, 10, 1
  ...
continue

and still be correct. This change on it's own would be rather trivial to make in the rules however there is one last form of the do-construct that complicates things significantly.

The previous two examples are both forms of un-labeled do-constructs. A do-construct can also be written as a labeled do-construct, such as:

       do 99 i = 1, 10, 1
         ...
99     k = k + i

When written in this format the line terminating the loop can be almost any executable statement (including continue and end do). Furthermore multiple labeled do-constructs can terminate on the same line. For instance

       do 99 i = 1, 10, 1
         do 99 j = 2, 20, 2
           ...
99     k = k + i

where both the inner and outer loop terminate on line 99.

I've spent a little time toying around with fixed for this but I haven't come up with anything particularly satisfying that didn't involved abandoning the more structured rules approach (i.e., getting rid of the multi-line do-construct rules and replacing them with the old do/enddo keywords.

In the Fortran code that I develop, we use our own custom preprocessor, and I would like to extend the language-fortran syntax to add support for this, as well as our custom file extensions.

I have tried the simple "include" solution given here: http://stackoverflow.com/questions/22363070/how-do-i-make-a-default-syntax-by-filetype-in-atom-text-editor, but in this case, no highlighting works -- even if I don't yet add the support for the preprocessor directives.

What would be the correct way to go about this?

What's the way to indicate how toggle comment should work (Command-/) in fixed-form source files? Currently, Command-/ inserts C-style comments. I tried adding this to my config.cson:

".fixed.fortran.source":
  editor:
    commentStart: "^C "
    commentEnd: ""

but clearly, that's not the way to insert a C in column 1... Any ideas?

Hi there,

When one writes procedures in types, and when this procedure has the name of an intrinsic function, coloration is wrong. See example below:

log should be white.

It seems to me that any word preceded by % should be considered as non-intrinsic.

Best wishes,

The following code is is for an enum, which is not detected/highlighted by the grammar:

!-----------------------------------------------------------------------------------------
! Enum type definitions
!-----------------------------------------------------------------------------------------
! Return codes
  enum, bind(c)
    enumerator :: &
         METIS_OK = 1, &            ! Returned normally
         METIS_ERROR_INPUT = -2, &  ! Returned due to erroneous inputs and/or options
         METIS_ERROR_MEMORY = -3, & ! Returned due to insufficient memory
         METIS_ERROR = -4           ! Some other errors
  end enum

Please see screenshot

Auto indent behaves wrongly after line 14. When I change pure function to function, auto indent behaves correctly.

atom version 0.141.0

The Atom.io deprecation cop shows the following deprecation warning:

Store package settings files in the settings/ directory instead of scoped-properties/
Called 2 times:

Package.loadSettings - C:\Users\lezar\AppData\Local\atom\app-0.189.0\resources\app\src\package.js:565:9
<unknown> - C:\Users\lezar\AppData\Local\atom\app-0.189.0\resources\app\src\package.js:187:43

Please see screenshot:

integer ... line 5 after type() :: x line 4 should not be indented.
This comes from line 4 being interpreted as a type definition like in line 1-3.

atom version 0.141.0

For some reason attributes in type definition statements are being arbitrarily skipped in some cases as shown below

This bug was not present in earlier versions of Atom and I believe it's a bug in first-mate possibly related to this issue. I'll see what I can do about fixing this but we may have to wait for a newer release of Atom to fix it.

I start typing the word "class" and it gets to "clas" and then atom freezes and the Atom Helper process consumes 100% cpu. I've narrowed it down to this package after disabling everything else and then trying them one by one. I've only been using Atom for a few days and it was working fine before and I was able to type the "Class" without issue and it just started.

It seems to affect all my .f90 files regardless of their directory. I did a fresh install of Atom, making sure to delete the app, preference files, hidden files, restarted my computer, etc and I'm still encountering this issue with no other non-default packages installed.

I'm running OSX 10.10.3, Atom 0.194.0 and language-fortran 1.5.1

Howdy @dparkins,

was just messing around with some c-bindings in atom and noticed that this package doesn't pick up the bind statement as needing some tlc. See below:

module example
  use iso_c_binding, only: c_double
  implicit none

contains

  subroutine square(a, out) bind(c) <-- See here
    real(c_double), intent(in) :: a
    real(c_double), intent(out) :: out

    out = a*a

    return
  end subroutine square

end module example

I'm not sure how this language is structured - if it is only a part of the modern grammar or if you need to include in all of them. I think we it should be included only in the modern grammar because the c-binding was added in F2003.

Cheers!
C

Just noticed that comments aren't working in derived type definition constructs. The fix for this is easy and I've already done/tested it on my local machine. I'll upload a fix tonight.

That's not an important issue, but since I came across... here it is.
& character in first place of a declaration inside a type declaration seems to mess it up:

I just noticed there is a change log file in the main directory. Sadly it stops at v0.3.0. I feel it's time to update it so I'm putting this here mostly as a note to myself to do so. Of course if anyone else wants to comb through my old commit messages they're more than welcome to! 😄

The Modern Fortran associate construct is not implimented

I'm trying to open an arguably large source code (~5000 lines of code) and the syntax highlighting makes Atom slower and slower until freezing completely the more I scroll down in the file.

I've tried disabling the syntax highlighting to make sure it was indeed the issue, and it works perfectly fine without syntax highlighting.

If you want to try with the same file, you can download this archive http://s-provencher.com/pub/contin/contin.for.gz that contains the .for file that I was working on.

Hi,

I'm surprised that the auto-indentation does not take into account the ampersand "&" at the end of a given line to add an additional indentation at the beginning of the next one, so as to be able to distinguish between new lines and lines being continuation of previous ones. For instance, after having key-binded tab to the auto-indent command, here is what I get when I only use tab :

Wouldn't something like this be more confortable :

?

class variables are not highlighted as shown below. This should be pretty easy to implement. I'll probably get around to it this weekend if someone else hasn't.

Hi,

First of all I'm sorry since I can't manage to install the very last package of language-fortran. I'm stuck to the one that is installed by default with atom 0.146.

The issue is that source is not highlighted, for instance during allocations:

Hi:

Here is the example code

      program test
!this is a comment
c no this is a comment
        print *, 'Hello' 
      end

And here is how it looks in the editor:

Is it possible to configure this to treat (!) - as a comment start in .f files as well?

Cheers

Consider the following code snippet:

function hello()

  IF ( (condition1) .AND. &
    (condition2) ) THEN
    CALL DUMMY (1, 32544, &
    'DUMMY1', &
    'DUMMY2')
  END IF

end function hello

function hello()

  IF ( (condition1) .AND. (condition2) ) THEN
    CALL DUMMY (1, 32544, &
    'DUMMY1', &
    'DUMMY2')
  END IF

end function hello

as can be seen from the attached figure, the if-then block does not work correctly when the condition is split over multiple lines.

Considering the the 'begin' match for the if-then-construct`` in https://github.com/dparkins/language-fortran/blob/master/grammars/fortran%20-%20punchcard.cson where(?=[^\n]*\bthen)``` is part of the match, would this net not exclude new-lines?

I am still new at the definitions of grammars in this way, but by replacing the remainder of the match with a .*? the syntax highlighting is corrected.

The fix appears to not work. I updated 'Fortran - Fixed Form' to v2.0.12.

I'm opening a file with .f extension, the grammer is "Fortran - Fixed Form". There are several #include statements which are not highlighted correctly. Also, when adding e.g. #ifdef statements they are not highlighted correctly either.

atom 1.3.3, language-fortran 2.0.8