Game Console Sorting Tag Matrix

[juliadin]

While we are adding more and more sorting tokens for certain consoles, it becomes more and more intransparent for the user which one of the tags sorts roms into which folders, which mappings exist etc.

I as a user would benefit from a table-like structure that tells me which tags sort roms where to see if a tag supports my device (well enough to use maybe).

I as a developer would benefit from such a table in that I know if a new tag has to be implemented for a console of if there already is one that I can use or write additional documentation for.

• Can something like this be generated from src/types/gameConsole.ts?
• or ... is it preferable to make this manually (i'd volunteer to transfer the current mappings to a table)
• or ... is this a bad idea because of documentation obsolesence or sth else?

[juliadin]

In the style of https://github.com/juliadin/igir/blob/docs-813-outputTokenMatrix/docs/output/rom_path_device.md

[juliadin]

Wrote a little extension to the class GameConsole to support outputting a markdown table for a requested set of tags, assuming the name of the property in the GameConsole is the same as the tag (which should be true atm). It fails to name the consoles though. I'd like to extend the constructor with a console name so it can be used in this table.

[emmercm]

I think the goal you stated in the original post is great, I clearly see the value of a table like this. The MkDocs site might be a difficult format to view the table in, though, as I think it has a limited width. We'll have to think about that.

I'm in full support of an extension like this, and we can brainstorm on how to build it into the doc build process. I haven't made any MkDocs plugins before, but maybe there's something there that can be done.

[juliadin]

I can look into MkDocs extensions and how something like this could look. I fiddled with automatic generation, having multiple tables with a few tokens in each .. but all that seems reeeeally clunky especially because MkDocs does not support scrolling headers or however to call it because of some details with the responsive design.

I have also thought about putting the tables in the documentation of the tag but that defies the intention of having an overview as a starting point.

Also: if the source of trouth for this was not the code but maybe a configuration file that is used to generate code (or be loaded and used by code) as well as generate the documentation .... do you think that would change anything?

[emmercm]

Yeah, I think a "sticky" header would really help for long tables.

I could see a JSON file or similar make the docs generation easier. I think Node.js actually allows imports of JSON files as objects, rather than needing to through fs.*() functions.