refactor: replace zmk,matrix_transform with zmk,matrix-transform

[lesshonor]

• While functionally equivalent, the hyphenated form of this property is more consistent with other ZMK properties and adheres to DTS style guidelines.
• ...Since I'm already touching a number of files, might as well update links to use Zephyr 3.2 documentation instead of 2.5 where appropriate.

---

This PR intentionally refrains from updating any boards or shields to minimize disruption, as some forks and/or utilities may currently expect/require the underscore form (Keymap Editor being one).

[joelspadin]

I think it may be confusing if the docs say one thing but all the code does something different. Can we check if it works to update the code to use hyphens and then build a user config repo that still uses an underscore when selecting a non-default transform? If we can confirm that it isn't a breaking change and the user config still selects the correct tranform, then we can update all the existing boards/shields to match this new documentation too.

[lesshonor]

Can we check if it works to update the code to use hyphens and then build a user config repo that still uses an underscore when selecting a non-default transform?

Sure. Here's what happens when you force &five_column_transform on the default (six-column) corne keymap.

n.b. The CI failure is unrelated to my changes:

Error: Failed to CreateArtifact: Received non-retryable error: Failed request: (400) Bad Request: number of artifacts reached artifact limit for job

[caksoylar]

To analyze your results, using zmk,matrix_transform = &five_column_transform; in a keymap with the keyboard definition having zmk,matrix-transform = &something is working as expected -- as it results in excess array initializer errors with a 6 col keymap -- right?

[lesshonor]

To analyze your results, using zmk,matrix_transform = &five_column_transform; in a keymap with the keyboard definition having zmk,matrix-transform = &something is working as expected -- as it results in excess array initializer errors with a 6 col keymap -- right?

Correct, as the user config repo commit describes. The 1000+ additional warning lines spewed out during the build action when there are too many elements are a much more obvious tell than having to painstakingly count the number of elements in two inconveniently-formatted devicetree nodes.

[caksoylar]

I think best would be to test and confirm that the transform choice was effective, but absent that the build warnings seem like a good sign.

[caksoylar]

Docs updates LGTM, thanks for updating the links as well -- they all seem to be live.

(I think it is a good idea in general too, given it is backwards compatible.)

[lesshonor]

I think best would be to test and confirm that the transform choice was effective, but absent that the build warnings seem like a good sign.

I've done that; I personally use this keymap, which draws on this module (and you're welcome to examine its last build)—but how do you propose I demonstrate the results? The number of nodes in the keymap file isn't modified by the selected transform, and there are no errors or warnings if it technically has too few keys. You can see zmk,matrix-transform and zmk,matrix_transform in the assembled devicetree of my test...
If you can tell me what you'd like to see, perhaps I could figure out how to show it?

[caksoylar]

I've done that; I personally use this keymap, which draws on this module (and you're welcome to examine its last build)—but how do you propose I demonstrate the results?

Maybe I missed it, but I didn't know that you had already tested it on a keyboard. Verbal confirmation is enough for me.

I guess you could write a unit test but I (personally) wouldn't think that is necessary.

[petejohanson]

Thanks!