Klipper documentation seems broken

[gandy92]

First, let me thank you for this wonderful plugin that I learned to appreciate while using Marlin. Now that I begin experimenting with Klipper I noticed that most of the klipper entries seem broken where "traditional" gcode commangs are concerned and mostly missing when it comes to those klipper specific "human-readable" commands and macros.
As far as I understand the plugin scrapes the respective firmware's gcode documentation page for the supported commands. Klipper seems to describe a few of the supported commands in details and apparently refers to other pages for the rest. Some commands like G10 are just mentioned and end up without a brief description in the plugin.
Klipper also allows defining all kinds of additional makros that can be used like the predefined ones. It would be fantastic to have some kind of documentation for those.
Would it be feasable to have some additional way of adding or eve modifying the standard information source for the languages, maybe by means of some json file structured like what updater.py feeds into all_codes.js? This information could be a kind of overlay to the scraped data, augmenting it with missing information (e.g. missing brief description, etc) and additional macros.

[costas-basdekis]

That's a good suggestion @gandy92, although I don't use Klipper, I've seen the quality of the documentation is worse.

We could definitely improve scraper, but I'm not sure where could we get data from. Do you have any idea how would we be able to do that? Is there another better source? I've thought about reading the Marlin codebase, but I haven't checked the Klipper one.

[gandy92]

Actually, I'm not sure either if the scraper can be improved - that would require a more or less strict structure in the documentation source which I currently don't see with klipper. I've quickly browsed through the klipper python code implementing the gcode (and enhanced) commands, but that too does not provide the necessary details to base the MarlinGcodeDocumentation's input off.

Maybe the klipper developers can be convinced to accept PRs to move the documentation structure to something that can be scraped as easily as the marlin documentation. If that can not be established, one alternative I can think of, is to provide independent klipper documentation data for the plugin.