FWIW and without being the authority, I would keep clear of Klipper’s config parsing in order to:
- Avoid the danger of regressions. History has shown that this is a sensitive area.
- Adding features and further complexity also increases the maintenance burden in this area.
From experience, there are three groups of “static” config issues:
- Issues preventing Klipper’s start in the first place, e.g., wrong or incomplete serial-paths in the
[mcu]section. There are more such problems, and typically their error messages can be cryptic. - Issues that “silently” might affect operation, e.g., TMC drivers - Klipper documentation and following chapters.
- Issues that only hit when a certain function is called, e.g., SAVE_CONFIG section 'bltouch' option 'z_offset' conflicts with included value.
To catch all three, the best thing would be some external validation that “imports” Klipper’s parsing rules.
An “extra” like proposed by @3dcoded would be nice as well, but will likely not work for number 1.
My dream would have been:
- Static analysis with a flexible rule engine that can be easily extended.
- Likely stand-alone. Being part of either Klipper, Moonraker, or the web interfaces always requires a successful start of Klipper.
- Proposals on how to fix certain issues and useful hints, e.g., “Often the BLTouch pin requires the declaration of a pull-up via
^.” - As a cherry on the cake: Some beautifier functionality, like indentation, etc.