You beat us to it! Highlights of this release include:
- LSP server for feedback as fast as you can type
- A dozen new rules, and more than a dozen moved out of preview, taking us to almost 90 rules, with around 60 on by default
- More powerful config file discovery and usage
- A more powerful
explaincommand to get help about rules from the command line - A new
configcommand to get help on settings from the command line - Some bug fixes
We’ve listened to a lot of feedback and improved our documentation, expanding it and giving more examples, as well as adding a logo and a badge:
Add it to your repo with:
[](https://github.com/PlasmaFAIR/fortitude)
To get the LSP server up and running, most editors just need some config and the latest version of fortitude in your $PATH. VS Code (despite being Microsoft, who wrote/maintain the LSP spec) requires a separate plugin: a preview version of which is available – it will also be released imminently, once I work out what I need to do to publish it on the VS Code marketplace.
I use Emacs myself, so if any VS Code users want to give it a proper stress test and give us any feedback before we publish it, that would be very gratefully received! 
The current roadmap includes integrating a custom C preprocessor so that we can track warnings through to the original source, and even apply fixes. We’ve got plans for more than 60 new rules, and we’d absolutely love to hear suggestions for more.
Future work will also include adding more semantic information from across a project, so that we can add even more rules. We have been looking into leveraging lfortran for this ability.
We are also still working on the formatter. There is an implementation on a branch that you can try out, but it may yet undergo a complete rewrite. Obviously formatting is a big source of disagreements and there usually isn’t one obviously correct answer, but we’d be interested to hear people’s opinions on whether our formatter should be like Python’s black/ruff format which have very little configuration (basically just line length!), or something more like rustfmt which is very configurable but with an opinionated config out of the box.
As always, we’d love to hear your feedback, especially suggestions for new rules – both things that are bugprone and those that are “just” style guidelines. Contributions are always welcome too – even if you don’t know Rust (and don’t want to learn!), helping improve our docs would be much appreciated!