Feature request: more intuitive transparent keys

[rszyma]

Is your feature request related to a problem? Please describe.

Currently, the transparent key _ resolves to a corresponding key in defsrc or base layer (respectively for layer-switch (with delegate-to-first-layer disabled) and layer-while-held). While this is well documented in config guide, it's not really intuitive.

Specifically I want to discuss transparent keys in stacked layers with layer-while-held. When user wants to "stack" multiple layers using multiple layer-while-held actions, it seems like what's expected is that transparent key redirect to corresponding keys on the previous (1 layer below), not the base layer.

Examples of users having this misconception:

• https://github.com/jtroo/kanata/issues/635#issuecomment-1865867932
• https://github.com/jtroo/kanata/issues/737#issuecomment-1942246224
• Also, me. I thought transparent keys redirect to previous layer, until I wrote this comment

Describe the solution you'd like.

I can think of a few possible solutions:

1. Replace the behavior of _
2. Add defcfg option that changes the behavior of _
3. Add a second transparent key (e.g. __) to have the new behavior, and keep _ unchanged. 3.1. Or vice-versa (make __ old, make _ new)

Describe alternatives you've considered.

Better documentation? But still, adding this alternative transparent keys behavior could help with implementating the solutions for both issues linked in the first section.

Additional context

No response

[jtroo]

This seems quite related to https://github.com/jtroo/kanata/issues/360 - the changes needed are in the keyberon library, since the library itself only supports base+active rather than layer stacking.

[rszyma]

In terms of implementation - indeed it seems like both issues would require similar internal changes to keyberon.

Both this issue and #360 suggest adding layer stack, and it seems to me that it would be unnecessary to implement #360 if this feat request was implemented. The opposite is not as much true. I've proposed this feature request mainly with _ in non-layer situations in mind: e.g. chords definitions, or positional (generic) keys actions. The other issue doesn't cover that at all.

Generally, this feature request's implementation of layer stack overall seems more fitting and coherent given current design of kanata (no new layer changing actions). My suggestion is to close #360 in favor of this one.