Delimieter highlighting fails

[Groundsel]

I am looking over a program written by someone else who did not believe in comments.  Delimiter highlighting is one of the useful tools aiding my comprehension and it works for most routines.   However, there is one where it does not.  I am using VS 2010 with Visual Composer XE 2012, SP1.  What sort of features of coding would make this fail.   I hasten to add that the routine compiles without complaining messages.  And the author did believe in indenting block levels.  I can't see anything wrong with his source code or the VS settings (which would have affected all routines).

However, I would like to know what can cause the delimiter highlighting to go off for the source code in a single routine.  I am hoping this is a fairly common and well understood phenomenon.  It need be, I can furnish the example.

[mecej4]

By "delimiter highlighting", do you mean "syntax highlighting"? Usually the text editor (or VS editor) does syntax highlighting based on the file suffix, so using an unusual suffix such as ".ftn" for a Fortran source file may cause the highlighting to disappear. I'd also expect that Fortran source that makes heavy use of C-preprocessor directives may not be displayed nicely. As far as I know, there is no standard regarding what constitutes "complete highlighting".

An example would be most useful.

[Groundsel]

I am sorry not to have replied sooner.  I was thinking inside the box about how to give you an example.   The attached zip is a suitable example provided one only loads the solution contained and looks with Visual Studio 2010 (as I did) at the routine "FINAL".  No need to compile it to check on the delimiter highlighting.   I can't figure out why it does not show.   As it happens, it did not really matter except for the precedent it seems to create.

[FortranFan]

FWIW, syntax highlighting - as mentioned by mecej4 in Quotes #2 above - works as it normally does with Visual Studio (VS) integration provided by Intel Fortran with VS 2017 and Intel Fortran Compiler 2018 Beta update 1.

 

[mecej4]

Groundsel, sorry, as a casual user of Visual Studio I find your post confusing. I don't know which delimiters you are talking about and how you expect their presence to affect the syntax coloring in the VS file display. I do not have your particular VS version (2010) with Intel's Fortran-related customizations, so my VS-2010 cannot open *.vfproj files.

Opening your project in VS2012, for which I do have IVF's Fortran customization, shows a potential problem:

     The second source file is named "Caller..f90". It is possible that the two dots in place of the expected single dot caused VS to think that this particular file was not a Fortran source file, and VS then did not apply your delimiter coloring choices to the file. Try renaming the file to "Caller.f90" and changing "Caller..f90" to "Caller.f90" in all the project files. Perhaps, after you do that, the VS editor will recognize the file as one to which your chosen color scheme should be applied. 

[Groundsel]

Sorry if this is a can of worms.  The program Caller was just context and probably should not have been included.  It would have been more useful to include another routine from the same program which did not have the highlighting issue. 

My understanding of the answers is that the high-lighting does occur in the routine FINAL if one uses later Visual Studio with a later Intel compiler than 2010 (which is what I have).  The high-lighting to which I was referring is the lighting up of IF blocks (select a line IF and the ELSEIF's and ENDIF should light up along with the IF itself.  Likewise, if I select DO, the ENDDO should light up too.  This is especially useful when one tries to understand someone else's programming.

As regards the obsolescence of my equipment, all the other routines (not included) in the original program show the kind of high-lighting described.   Only this one does not and I was hoping someone could tell me why.   However, it is not a burning issue.  I have managed the program changes needed and can put this to bed.  I was wondering, however, what made this routine different in this vein than the others.

[mecej4]

Yes, I see matching keywords in block constructs such as IF...THEN...ELSE...ENDIF getting highlighted if one of the keywords is clicked on -- most of the time. In fact, clicking on THEN highlights the corresponding IF and ENDIF, but only if the IF and THEN are on the same line. Your FINAL.F90 has one instance on line-89 where the IF line is continued to line-90, with the THEN on line-90. In this case, clicking on the THEN fails to light up the IF and ENDIF.

My view is that you should never expect the syntax highlighting feature of any text editor or IDE to know the syntax of Fortran to the same degree of completeness as the compiler.

[Groundsel]

Thanks,

My concern was that some issue was lurking about which I was unaware.  One expects the compiler to be more savvy than the IDE and I guess this is a case in point.