I keep getting squiggly lines in VS Code whenever I save my file with a .f extension. Even though my code runs fine, I have already installed the Modern Fortran extension but the squiggly lines persist. Here is a screenshot of the code.
The .f extension is usually used for old-style fixed-format Fortran. Use the .f90 extension for modern (post-1990) free-format Fortran, as you are using.
Thanks @gnikit, and that thread is exactly why we’re starting with .f. However even for me VS Code + Modern Fortran is quite important so the fix to override the default would be very helpful if we are to continue with .f. I understand that it’s subject to your available time, of course.
I’ve got a patch ready. Will push and make a pre-release when I get back. In the meantime, we can manually pass -ffree-form to the extra linter args option.
Another thing I’ll have to look into is propagating this option to the language server. There’s an option specific to fortls that makes this work but I think checking and propagating the "files.associations": ... might make things easier to configure.
first of all, great work with this VS extension ! Sure it helps (A LOT) hundreds of Fortran coders using VS as the main code editor (myself in primis ).
As far as I understand, there is the opened discussion about making .f the default Fortran file extension, correct me if I’m wrong. Which I’d fully support.
If that’s the case, what about old (fixed form) .f FORTRAN code files mixed with Modern Fortran code .f files? In that case, should a user manually specify the form for each file present in the tree (if that’s even possible, but might be easy to add)?
Have you thought about the linter automatically infer the form by parsing the first few lines of the file content (and then store this info in some cached data somehow, for all workspace folder trees currently opened)?
I am glad to hear that you (and the general community) find the extension useful .
If that’s the case, what about old (fixed form) .f FORTRAN code files mixed with Modern Fortran code .f files? In that case, should a user manually specify the form for each file present in the tree (if that’s even possible, but might be easy to add)?
Basically, the issue here was that VS Code allows for user overrides (global/per project/per file) and we have coded the extension with that in mind. However, we did not consider that the compilers we use for linting would need to be explicitly told what type of source file we were trying to parse. That has now been fixed.
Have you thought about the linter automatically infer the form by parsing the first few lines of the file content
That is what fortls (the language server) does. It has a series of cheap heuristics when parsing sources that are only true in fixed form. For the core of the VS Code extension (i.e. outside of the language server) knowing that info before-hand would not make a difference (it needs a substantially more asynchronous approach of determining the type of language used by the file than the language server could offer).
Clarification
To be clear to all users, we are NOT changing the default behaviour of the extension, or forcing .f to be considered as free-form. We simply permit the user to override the extension’s defaults, if they choose so and have the linter, syntax highlighting and language server, work as expected.