glyph customization questions

[SethMilliken]

Loving the keymap-drawer now that I've delved into customization. A couple of things I'm interested in doing that I haven't been able to figure out on my own.

1. Is it possible to do keycode map translation for entities with & in their name, e.g.:

'&caps_word': 'CAPS WORD'

2. Is it possible to do keycode map translation for multi-word entities? e.g. I have a parameterized macro called &act that takes a parameter, and I want to translate its occurrences in my keymap:

'&act LESS_THAN': '&act <'

or

'&out OUT_USB': $$mdi:usb$$

3. Is it possible to have multiple glyphs in a keycode map translation? e.g.

C_PP: $$tabler:player-play$$ $$tabler:player-pause$$

or

&bt BT_SEL 0: $$mdi:bluetooth$$ $$mdi:numeric-0$$

Just to be clear, none of the above work; I'm trying to figure out how to get something like them to work.

Here is my keymap_drawer.config.yaml for reference.

[caksoylar]

Hey, thanks for using the discussions feature!

If I understand you correctly, both 1. and 2. can both be solved by using the raw_binding_map property rather than the keycode map. This field is for verbatim replacements of bindings, rather than replacements for keycodes specifically (which are handled by qmk_keycode_map and zmk_keycode_map separately). This field is looked up before anything else, so if any key in it exists the rest of the parsing will be skipped and the value will be used.

Unfortunately 3. is not possible at the moment and glyph substitution works only if the glyph spec is the only item in the field. There are technical blockers to adding multiple glyphs in a single field since their placement is manual.

However, you can consider putting different glyphs in different key fields, e.g.

parse_config:
  raw_binding_map:
    '&bt BT_SEL 0': {t: $$mdi:bluetooth$$ h: $$mdi:numeric-0$$}

[SethMilliken]

This is great. I didn't even know there were other addressable fields, although in retrospect it makes sense since other parts of the plumbing take advantage of that. Those fields together raw_binding_map look like they'll do the trick. Thank you, again!

[SethMilliken]

I guess a natural follow-up question is: where are these particular things documented (even it's just the code)? There seem to be a lot of components assembled here, and diving in for the first time it can be difficult to figure out how it all fits together and where to look to understand any given piece of the pipeline.

[SethMilliken]

Just in case someone else uses this for reference, your example needs a comma between the fields: {t: $$mdi:bluetooth$$, h: $$mdi:numeric-0$$}

I also swapped the glyphs in each field. Pretty happy with the results:

[caksoylar]

I guess a natural follow-up question is: where are these particular things documented (even it's just the code)? There seem to be a lot of components assembled here, and diving in for the first time it can be difficult to figure out how it all fits together and where to look to understand any given piece of the pipeline.

Currently README is the "user manual" and the reference for anything that goes in the keymap YAML (as output of parse and input of draw) is documented in the KEYMAP_SPEC. (I now realize SVG glyphs are documented only in the readme section and not mentioned here.)

Configuration options are documented in the code at config.py but perhaps a CONFIGURATION.md might be better where each option can be elaborated further.

I'd appreciate any feedback on better organization options or anything you were missing from the docs!

Just in case someone else uses this for reference, your example needs a comma between the fields: {t: $$mdi:bluetooth$$, h: $$mdi:numeric-0$$}

Sorry about the comma! For reference it is YAML syntax for mappings, so you could also define them multi-line etc.