FPM Integration with Visual Studio Code - Discussion

[gnikit]

I would like to start a discussion about how to integrate FPM with vscode, functionality we want to be present, how we want the UI to look like and the changes that would need to be done in FPM to make this happen.

I already have some ideas on this briefly noted in fortran-lang/vscode-fortran-support#471 but I much prefer it if this was a combined effort. We can take inspiration from the CMake extension, these are the features I think we should include

1. VS Code Functionality

1. Ability to "Scan for Kits" i.e. detecting compiler configurations present in a system and allowing the user to select one
2. Initialising the FPM part of the extension when an fpm.toml is detected
3. Add a file watcher to fpm.toml to propagate changes of state into the VSCode extension and the builds

2. VS Code UI

1. Register a new section in the sidebar (i.e. Activity bar) use FPM logo
2. Display a list of targets (executables, libraries)
3. Display tests in "Testing" section of sidebar or within the normal Activity bar
4. Allow Building, Debugging and Running of targets
5. Allow setting options to fpm.toml through a UI
6. Allow setting additional options, not part of the manifest, e.g. special compiler flags, link and include commands, though a UI and save to a cache or a response file
7. What options should we allow in the settings.json if any?

3. FPM Functionality

1. Add option to produce build files, e.g. .mod, .smod, any preprocessor files, etc. under a deterministic path to be used by linters. Probably best if a new subcommand tools is added to hide these options away from the general user base
2. Any ideas for improving the Manifest to include options from point 2.6

---

Please share any additional ideas, features you would like to see or comments you have about integrating fpm with your code editor.

[LKedward]

Thanks for starting this Giannis @gnikit and apologies for the late response!

I'm excited for this development to the VSCode extension (though I might not be able to contribute directly).

All your points sound good to me in general, some remarks:

2.5 This would be great, but I think it might be difficult to programmatically modify the fpm.toml file in such a way that doesn't completely reformat it in a potentially undesirable way
2.6 This would be really useful to fill a gap in the existing fpm manifest functionality
3.1 Instead of a deterministic path, could fpm communicate the output paths to VSCode somehow perhaps?

If I have any other thoughts, I'll post them here.

[gnikit]

2.5 This would be great, but I think it might be difficult to programmatically modify the fpm.toml file in such a way that doesn't completely reformat it in a potentially undesirable way

What I was thinking was that when you edit the fpm.toml through the vscode UI it would change just that field with whatever formatting we specify internally in vscode, without reformatting the entire file. In general, I would rely on a formatter to get a consistent look. Also, I think that when using ease-of-use tools like this one there is the understanding from the user that formatting styles might vary and it is up to the user to maintain a consistent format to their files.

2.6 This would be really useful to fill a gap in the existing fpm manifest functionality

I think so too and because we control both the fpm Manifest and the vscode extension we can decide how that cache file looks like with every release of the fpm. We can also use it as a test bed to experiment with potential options to the fpm Manifest.

3.1 Instead of a deterministic path, could fpm communicate the output paths to VSCode somehow perhaps?

So the path would be ideally deterministic because the linter continuously generates .(s)mod files (on filesave) that should never be used for compilation. My thinking was that it is easier to implement if we have a deterministic path specifically for linting. However, upon further reflection I think that fpm communicating the path to vscode has certain advantages albeit more expensive since we would have to spawn an instance of fpm to fetch mod output path every time we lint (naive solution) or every time the internal path of the build changes (by watching the files fpm.toml and fpm cache proposed in 2.6 for changes)

For example:

For every build, if a lint path is requested a path like this will be returned

.
├── gfortran_1798BA9AB07BDE5E
│   ├── metis
│   └── .vscode
│       └── lint
└── gfortran_6B41AC2D6C9C7341
    ├── metis
    └── .vscode
        └── lint