Easier extensibility with custom layers

[moben]

Let me start by saying: I love what you have created with miryoku, it is excellent and I use it every day 👍

That said, I often want to have one or two extra layers on some of my keyboards and this is currently a bit tricky to maintain without just copying the generated code and modifying it.

A common modification that I want is to add extra layers between BASE and the seven top layers. An example would be a qwerty layer for games with non-rebindable keys or a "normal" layer that I can activate when someone else needs to use my keyboard (see e.g. manna-harbour/qmk_firmware#24). Most keyboards have enough keys to put a toggle for such rarely used functionality but it's a bit annoying to maintain and rebase as a patch set on top of the tangled miryoku C code.

I would love for something like -DMIRYOKU_EXTRA_LAYERS="QWERTY, GML, GMR, " or even -DMIRYOKU_EXTRA_LAYERS="QWERTY, GML, GMR, GML_QWERTY, GMR_QWERTY, " to work but I'm not sure this is even really doable without going through preprocessor hell.

One alternative that would be a lot easier to maintain would be to

1. Statically assign layer numbers for NAVR, MOUR, MEDR, MBO, FUNL, NSL, NSSL, leaving some space above and below (or maybe allow setting a define for where they start, so a user can assign custom layers either below or above).
2. Create defines for all of the different possible base layers (and GML/GMR combinations if you accept the linked PR)
3. Allow the user to insert the layers with another define

These would allow slotting in e.g. the mentioned qwerty layer above BASE by just specifying -DMIRYOKU_EXTRA_LAYERS="[1] = MIRYOKU_TAPHOLD_QWERTY. But the user would have to maintain the usable layer ranges manually.

Now that I've written it all down it seems a bit involved, but maybe you have some suggestions on how to do this. (Or if you think this should just not be part of miryoku.org then that's of course also fine)

[manna-harbour]

Thanks for the suggestion!

Hopefully manna-harbour/qmk_firmware#24 will cover most of the use cases for this.

If it's still needed after that, and we can work out a clean implementation I'd be happy to add it.

[manna-harbour]

This was linked from manna-harbour/qmk_firmware#32 but the original link was lost during the transfer.

[manna-harbour]

See #48.