Associating actions between layers

[cvsguimaraes]

I understand one could simply compose all possible actions for a given key directly in the base layer at once, but distributing them across layers is better as it improves readability and maintainability. Unfortunately it seems that this approach limits us to using layer switchers, chords, etc since there’s no way to reference the corresponding action from another layer dynamically to feed then to tap-hold and tap-dance variants.

Is there a way to ‘fetch’ the action for the same key position from a different layer?

Example for context:

(defalias
  x (tap-hold 150 150 x @sym)
  sym <exec action from symbols at the same index from the current layer action being evaluated>
)

(defsrc           a b  c)
(deflayer base    a @x c)
(deflayer symbols • !  •)

I naively attempted to activate the symbols layer followed by a transparent key, but it isn't meant to be used that way. Would appreciate any insights or possible workarounds. Thanks!

[gerhard-h]

I'd love to have (layer_engage symbols) or variable style $engage_symbols - it could be tricky to implement, though.
If done during 'preprocessing', an alias/template containing engage must be automatically duplicated for each different position it is used at.

If there were a (set_base_layer ...) functionality, maybe it could be combined with transparent keys to give this functionality?

P.S. @jtroo Why do variables not work in defsrc?

[cvsguimaraes]

If I understood it correctly, a similar behavior to what you described here would also be useful in this scenario, not sure.

[gerhard-h]

I really missed transparent keys are meanwhile layer aware
** layer-while-held workaround (working)**
Stack both layers on top op each other
(multi (layer-while-held symbols) (layer-while-held numbers) )
now in numbers layer you can use (tap-hold 200 200 1 _ ) where _ represents the action on the symbols layer (tested)

** layer-switch / base layer workaround (untested)**
since you can't use layer-switch anymore you must emulate it with virtual keys
(defvirtualkey switch_base (multi (layer-while-held symbols) (layer-while-held base)) )
This workaround is only able to pull from one layer
I can't use this myself because it messes with on-idle state.

** workaround with late layer activation (promising)(failed)**
(multi (on-press press-vkey vcaps) _ (on-release release-vkey vcaps))
(multi (layer-while-held vcaps) _ )
(multi (layer-switch vcaps) _ (layer-switch...

In all cases _ will ignore the layer operation :(

Replacing multi with macro is no possible because macro doesn't allow transparent key. Why?

[jtroo]

Variables not working in defsrc I believe was intentional to force less indirection with the intent of clarity in defsrc key names. I don't feel strongly about it though.

[jtroo]

Macro doesn't allow transparent today because its execution is part of a different subsystem to other actions, such as tap-hold; and that system doesn't understand how to activate the majority of actions.

Macro can activate virtual keys because virtual key activations generate new input events into the keyberon state machine.

[cvsguimaraes]

@gerhard-h

** layer-while-held workaround (working)**
Stack both layers on top op each other

Neat, not pretty but I made it work:

• Enabled delegate-to-first-layer and used alias-to-trigger-on-load to keep a vkey pressed
• Made symbols to be my base layer then used the vkey to have my original base layer always active on top

Now _ resolves to the symbol associated on that key slot. It still would be nice to delegate a transparent key to arbitrary layers though; this way users could also use layers as a layout oriented dictionary of actions.

[gerhard-h]

feel strongly about it though

Off topic: I'm a fan of deflocalkeys but it is a little bit cumbersome. I still use definitions like this (defvar $y = z) depending on interception/layout language/keyboard but I can't use $y in defsrc
If I could variables would be an alternative localization method.

[gerhard-h]

´(unmod _ )´ ´(unshift _ )´ also don't allow transparent keys. Is this the same problem as with macro?

[jtroo]

Yes; in hindsight unmod / unshift may have been better off not allowing keys within; because I think this should work fine with (multi _ (unshift nop0)); which is a configuration style others have used to work around this.

[gerhard-h]

So I could do an IBM style CAPS layer (shift=temporary lower case) independent of the actual letters
(deflayer CAPS @Cap @Cap @Cap...

(defalias Cap (fork (multi lsft _ ) (multi _ (unshift nop0)) (rsft lsft)) )

great.