Includes get rearranged

[mazharenko]

As a custom (still QWERTY) OS layout user, I had been suffering editing and reading the keymap both in the keymap file and in keymap-editor since neither the referenced codes in the keymap file nor displayed symbols in keymap-editor reflect the actual symbols that are printed in my IDE or whatever. For instance, in the example below there is a N9 key press. However, for the English Universal layout it will be the left parenthesis symbol.

I thought that would be great if there was a way to somehow map LEFT_PARENTHESIS to N9 and then assign LEFT_PARENTHESIS to the key. It then would be sent as N9 to the OS but printed as left parenthesis thanks to the Universal Layout in the OS.

I found that LEFT_PARENTHESIS is just (LS(ZMK_HID_USAGE(HID_USAGE_KEY, HID_USAGE_KEY_KEYBOARD_9_AND_LEFT_PARENTHESIS))) which is defined in keys.h and I can just redefine its value. And it works well. However, when saving in keymap-editor, it keeps rearranging the includes, and nothing is overriden.

I could introduce some custom key codes that would be OK for manual editing, but not fancy in keymap-editor.

[nickcoutsos]

Hmm, yeah, that's unfortunate. Keymap Editor re-arranges include statements mostly for consistency (because it may add or remove them based on behaviors used) but ideally it shouldn't mess with headers that aren't in the subset it manages.

I think what's happening is that it picks the correct position for those lines based on either the last line with an #include statement or the first line before the root node starts. I might be able to adjust that to always keep local includes at the end of the list but I'm not sure when I'd be able to get to it.

As a workaround I think you can move your include inside a root node and the editor won't consider it during that sorting. You may still run into issues with the editor while using things like the send string macro, however, unless that was just from experimenting with your re-mapping.

Also maybe it goes without saying but because it's not evaluating pre-processor directives in the editor it won't actually understand that your keys haven't been redefined. In this case it doesn't look like it's a big problem but when changing bindings if you've selected LEFT_PARENTHESIS it may think it has LSHFT applied implicitly.

[mazharenko]

Thank you for the response.

The workaround works like a charm.

Yeah, I gave the not-merged-yet Send String Behavior a try to address the issue. Could work, but would be way too cumbersome.

Feel free to close the issue unless you think the arrangement logic needs reconsideration.