Modern Fortran VS Code extension migrating to Fortran Lang on GitHub

I was wondering how the Fortran Language owners and the wider community would feel about inheriting the Modern Fortran VS Code extension? Both the repo host and I are happy to pass it over to an organisation, to ensure continuous future support for the fairly large user base.

Also, I hope with Fortran Lang leading the development, other projects like lfortran, lpython and fpm can use the extension as a test bed to improve and possibly gain wider adoption since Fortran Lang will have full control of the development stack.

A similar argument can be made for using the VS Code extension to improve the chances for further development of Fortran Lang projects (current or future ones), although I doubt that such attempts would yield any results.

I am happy to still do dev work for the extension, but it would be good to have a few more eyes overlooking the changes. Also, it would be great if more people were able to contribute without me having to review each PR.

The VS Code API is very well documented to adding to the project is relatively easy. Same goes for testing and publishing, although I have automated most of these actions.

Some points to consider:

  1. The extension publisher ID krvajalm will have to change to a publisher owned by the Fortran Lang organisation. This probably means that the releases under Fortran Lang will not automatically install to the current users. I see two solutions for this:
    • Add a prompt message in the last version of Modern Fortran under krvajalm which redirects the users to install the “new” extension under the new publisher ID. This would reset the install, download, ratings, etc. counters.
    • Message Microsoft in the off chance they can rename the publisher ID without having to effectively start from scratch.
  2. This is a good time to change the extension name from linter-gfortran to something more appropriate like fortran. This would probably run into similar problems as 1.

Let me know what you all think, and if the Fortran Lang owners are happy with this I can start the process.


Hey @gnikit, that’s an interesting proposition, although I cannot speak for the whole Fortran-lang community. Maybe we could create a poll to learn how many of the Fortran Discourse readers use VS Code?

I noticed recently that Julia has discontinued support for their own Juno IDE, focusing instead on the Julia for Visual Studio Code. This however lives in it’s own GitHub organization: Julia extension for Visual Studio Code · GitHub. Since the Fortran open source community is much smaller, it perhaps makes sense to have more vertical integration. There’s always a risk if VS code sees a decline in popularity, then the Fortran-lang namespace will be left with abandonware.

Some developers say we are living in “The Era of Visual Studio Code”, and I know that many resources for new programmers recommend it so it’s probably still growing in popularity. Having good Fortran support is a must if we want to see newcomers stay and promote Fortran as a contemporary programming language.

Are there parts of the VS Code extension which could be potentially re-used in other text editors or programs (e.g. the Fortran language server)?

In principle it is possible to maintain the Modern Fortran VS Code extension under Fortran-lang namespace. It has been done with other projects before (fftpack, minpack, test-drive) and we are happy to host more Fortran related tooling and libraries under the Fortran-lang namespace, if the current maintainers are happy with this.

While I like your proposal to maintain the VS Code extension under Fortran-lang, keep in mind, that such a change will not magically increase the number of active contributors and maintainers. For the transferred projects so far the maintainer/contributor situation stayed mostly the same. However, you might gain more visibility to encourage a more community driven development model.

The technical bits involve an admin enabling the repository transfer and the setup of a new team with the correct access. Feel free to ping me or the other admins once the decision is made, we will take care of the technical details.

1 Like

My drive to pass the extension on a wider community is because currently, and AFAIK, Modern Fortran is the only actively maintained Fortran extension for VS Code, Atom and Visual Studio (Atom and VS extensions have not been updated in a while)

Also in terms of functionality, it is the only extension I know of that has native integration with a Language Server, full debugger support and multiple formatters, so from that point of view I think it would be a good idea to try and keep it alive.

Generally I don’t think that that is possible. The language server itself is reusable but the client implementation that hooks to the server is Editor dependant. Same thing applies to formatters and debuggers. The syntax highlighting can be reused by any editor that can use TextMate grammar. Although, I think we are slowly shifting towards a hybrid syntax highlighting approach where some scopes are provided by TextMate files and some by the language server.

Yes, that is understandable. My hope is, as you said, for the community to engage a bit more actively with the development process, but even if they don’t that is fine.

The extension is complete and self sustaining for the most part. The only maintenance required is issuing once every year the authentication tokens for publishing on the VS and OpenVSX stores and merging/resolving the dependabot PRs.

If all owners are happy I can start the transfer process next week.


I am all for maintaining this under fortran-lang, and I was hoping @gnikit could also do a video call with anybody interested and show them how to contribute. We can record it and post it online, so that newcomers know how to contribute to the extension.