Correct column alignment for generated keymaps

[nickcoutsos]

I was looking at a keymap someone shared in the ZMK Discord server and it was pretty difficult to read due to the alignment of bindings for the right half of the keyboard. Although the layout in info.json provides the correct graphical positioning in the app, the generated devicetree and JSON code don't have the same textual formatting which is critical for helping people to debug issues and misunderstandings.

Changes

• Updated the layout definition to at least make sure the right half mirrors the left.
• Updated some of the labels to match the default keymap (this has no functional effect but it makes it easier to understand the layout definition)

Old:

      =,   1,   2,   3,   4,    5, mod1,  mod2,    6,     7,     8,    9,     0,    -,
    Tab,   Q,   W,   E,   R,    T, mod3,  mod4,    Y,     U,     I,    O,     P,    \,
   Caps,   A,   S,   D,   F,    G, mod5, LCtrl, LAlt,               LGui, RCtrl, mod6,   H,    J,   K,   L,   ;,      ',
 LShift,   Z,   X,   C,   V,    B,  1U1,   1U2, Home,  Ped3,  Ped4, PgUp,   1U3,  1U4,   N,    M,   ,,   .,   /, RShift,
   mod7,   `,   \,   V,   B, Bksp,  Del,   End, PgDn, Enter, Space,   Up,  Down,    ,,   ., mod8

New:

      =,   1,    2,    3,     4,   5, mod1,                                       mod2,   6,   7,    8,   9,   0,      -,
    Tab,   Q,    W,    E,     R,   T, mod3,                                       mod4,   Y,   U,    I,   O,   P,      \,
   Caps,   A,    S,    D,     F,   G, mod5, LCtrl, LAlt,             LGui, RCtrl, mod6,   H,   J,    K,   L,   ;,      ',
 LShift,   Z,    X,    C,     V,   B,  1U1,   1U2, Home, Ped3, Ped4, PgUp,   1U3,  1U4,   N,   M,    ,,   .,   /, RShift,
   mod7,   `, Caps, Left, Right,      Bksp,   Del,  End,             PgDn,   RET,       SPC,  Up, Down,   ,,   .,   mod8

Some commentary

The inclusion of some of these keys is confusing... even weird. I understand there are a couple of switches for optional foot pedals but there are others that seem to exist as placeholders. If you're ever considering a breaking change I would recommend modifying the matrix transform (or provide an alternate) to move these so that they're visibly separate from the regular keys. As long as the app is reading binds from the JSON file then it would be relatively easy to have a script take care of the change for users if/when they want, and not break compatibility for users who are depending on the keymap editor.

It would also be possible to move the thumb cluster keys down so that the overall width of the keymap file is lower... recently GitHub seems to have forced text wrapping when reading code which can be a problem generally for ZMK keymaps.

[ReFil]

Hi, thanks for doing this, there's two pedal keys per side as well as the ability to replace the 2u keys in the thumb cluster with 2x1u keys and the matrix is configured with this in mind, which accounts for the extra seemingly unused keys. I can definitely see how it could cause confusion though

[ReFil]

Just giving this a quick look over and it looks good, I wasn't aware you could have it add whitespace like this when I originally created the files, kudos for implementing that. It's really clever 😊, I'll double check everything later and merge it in

[nickcoutsos]

Sounds good.

I wasn't aware that the thumb keys could be replaced with two 1u keys, is that documented? I remember seeing a teardown a little while ago and it didn't seem like the thumb PCB had multiple switch locations, but maybe that's changed. If a user did opt for that layout they would have to make their own changes to info.json to have the keymap editor support it, right?

I've never gone too deep into supporting alternate layouts for a keyboard, but technically you can have multiple layouts defined and the editor should either look for one keyed with "default" or else grab the first available layout. It would still be a pretty manual change, though.