Feature request: Layer action triggers

[mdSlash]

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

Yeah, I’d like to simulate a tap-hold action without a timeout. The reason is that the delay can be frustrating at times, as I want to wait until the timeout is up before activating the held layer.

Describe the solution you'd like.

I’d like to suggest a new feature that would allow us to run specific actions when entering or leaving layers. The idea is to add a new configuration entry, such as deflayeractions to make this happen.

Describe alternatives you've considered.

The deflayeractions entry should take at least two arguments:

1. The name of the layer we’re working with.
2. One or more actions to trigger based on what happens in that layer.

How It Could Look

(deflayeractions 
  layer-name
  (enter <action>)                   ;; Action to trigger when entering the layer
  (release <action>)                 ;; Action to trigger when leaving the layer  
  (release-op <action> (<key>))      ;; Action to trigger when leaving the layer
                                     ;; after pressing specific keys defined in 
                                     ;; the key list or any key.
  (release-no-op <action> (<keys>))) ;; Action to trigger when leaving the 
                                     ;; layer without pressing specific keys
                                     ;; defined in the key list or any key.

Additional context

No response

[jtroo]

Maybe try switch and virtual key actions: simulator link

(defsrc l)(deflayer base @l1)(deflayer layer1 _)
(defalias
 l1 (multi (on-press press-vkey layer1)
           (on-release release-vkey layer1))
)
(defvirtualkeys
 enter-action1 w
 release-action1 x
 cond-release-action1 (switch
  ;; op
  ((key-history a 1)(key-history b 1)) y break
  ;; no-op
  () z break
 )
 layer1 (multi
  (layer-while-held layer1)
  (on-press tap-vkey enter-action1)
  (on-release tap-vkey cond-release-action1)
  (on-release tap-vkey release-action1)
 )
)

[gerhard-h]

the problem is that in this input order simulate cond-release-action1 is skipped completely (z expected), I have no idea other than brute force checking for key presses on every single key on the layer.

[jtroo]

z expected

You need to add extra ending time to the simulation:

original:    d:l t:10 d:c t:10 u:c t:10 u:l
modify to:   d:l t:10 d:c t:10 u:c t:10 u:l t:100

[gerhard-h]

I had the idea to scan for no-op with input-history, that simplyfies implemenation.

;; no-op
((input-history virtual enter-action1 3)) z break
;; op
() y break

though i don't know why the magic number is 3 ?

simulate

[mdSlash]

Maybe try switch and virtual key actions: simulator link
...

Thanks, @jtroo ! It worked, although the structure is a bit complex for me. I also have a question: can the trigger in the switch be one of the corresponding keys in defrc?

[jtroo]

I'm not certain what you mean by trigger but perhaps you're looking for the input items in switch?

https://github.com/jtroo/kanata/blob/main/docs/config.adoc#input

[mdSlash]

Similar to key-history, but with keys corresponding to defsrc. I've tried input-history real, but it doesn't seem to be the case

[jtroo]

input-history real sounds like it should work. Of note is that virtual keys and real keys go into the same queue history. The correct recency number for your use case might not be what you initially expect.

[mdSlash]

I had the idea to scan for no-op with input-history, that simplyfies implemenation.

;; no-op
((input-history virtual enter-action1 3)) z break
;; op
() y break

though i don't know why the magic number is 3 ?

simulate

Yes, the magic number is 3, and I also do not know why that is.