fix(emulation): Shift+digit types the num-row symbol

[niiico69]

Fixes #94, follow-up to the hold_taps.dtsi part of #73.

Ten mod-morphs on S_N0..S_N9, in a new emulations/num_row_shift.dtsi, guarded by KB_LAYOUT_AZERTY + ErgoL/Lafayette emulation (both num rows are identical).

Not in emulations/ergol.dtsi: that file is included after the keymap layers, so it would only fix the NumRow layer. #94 is reported on NavNum, which is emitted earlier — hence the include right after hold_taps.dtsi.

Built on ZMK main (cradio_left / nice_nano_v2): with KB_EMULATION_ERGOL, &nm0..&nm9 land in the NumLock, NavNum and NumRow layers; without emulation, nothing is emitted.

[fabi1cazenave]

I might be pedantic, but I don’t expect this to show up in the general case. Is there a way to include num_row_shift.dtsi directly from the ergol.dtsi and lafayette.dtsi files instead?

[fabi1cazenave]

ErgoL/Lafayette emulation (both num rows are identical).

To be sharp: they’re not perfectly identical and the Lafayette NumRow might change soon, but yes, for now we use the Ergol NumRow for both. Maybe we could take the opportunity of this PR to create an emulations/ergol_num.dtsi file containing what you propose in emulations/num_row_shift.dtsi and the following section?

// hybrid Ergol/Lafayette NumRow
&num_row_layer {
  display-name = "NumRow";
  bindings = <SELENIUM_KEYMAP_BINDINGS(
    &trans  ,  C_EURO  C_LGQT  C_RGQT  S_DLLR  S_PRCNT  ,   S_CARET S_AMPS  S_STAR  S_LPAR  S_RPAR  ,  &trans ,
    &trans  ,  S_N1    S_N2    S_N3    S_N4    S_N5     ,   S_N6    S_N7    S_N8    S_N9    S_N0    ,  &trans ,
    &trans  ,  C_LODQT C_LDQT  C_RDQT  C_CENT  C_DEG    ,   S_MINUS S_COMMA S_DOT   S_COLON S_FSLH  ,  &trans ,
                             &trans , C_NBSP , &trans   ,   &trans , C_NBSP , &trans
  )>;
};

[fabi1cazenave]

Oops, I’ve missed this part:

Not in emulations/ergol.dtsi: that file is included after the keymap layers, so it would only fix the NumRow layer. #94 is reported on NavNum, which is emitted earlier — hence the include right after hold_taps.dtsi.

Makes sense… Then maybe we could redefine the NavNum layer in the emulations/ergol_num.dtsi file, along with the NumRow one? I understand it means more code duplication, but I’d prefer a bit of duplication if it helps keeping things uncoupled.

@Nuclear-Squid any opinion on this?

[Nuclear-Squid]

My knee jerk reaction is that declarations of layout-specific behaviors should only be defined in the correct layout-specific file (i.e. aliases/azerty.h or emulations/ergol.h, in this case). I feel like this solution works but won’t really scale.

Overriding layers definitely keeps things uncoupled, so even if it makes things a bit slower to change in the long run, I do prefer this approach. We’re already overriding numrow, since we need a couple of changes, and to me it feels a lot simpler to maintain one more duplicate then a "second-stage alias system"