Feature request: allow fakekey in fork

[rszyma]

Is your feature request related to a problem? Please describe.
Yes. I'm trying to have a single alias that will toggle between 2 layers. I'm trying to achieve that by keeping state in a fakekey. However, it looks like checking if fakekey is pressed in fork is not supported and results in an error.

(deffakekeys
  colemak_enabled XX ;; fake key for keeping state of qwerty/colemak toggle
)

(defalias
  ;; The fork action accepts two actions and a key list.
  ;; The first (left) action will activate by default.
  ;; The second (right) action will activate if any of the keys
  ;; in the third parameter (right-trigger-keys) are currently active.
  ;;
  ;; Toggle between colemak and qwerty.
  tgl (fork
    (multi
      (layer-switch colemak)
      (on-press-fakekey colemak_enabled press)
    )
    (multi
      (layer-switch qwerty)
      (on-press-fakekey colemak_enabled release)
    )
    (colemak_enabled)
  )
)

19:00:16 [INFO] kanata v1.3.0 starting
19:00:16 [INFO] process unmapped keys: false
19:00:16 [INFO] NOTE: kanata was compiled to never allow cmd
19:00:16 [ERROR]
  × Error in configuration file
    ╭─[kanata.kbd:33:1]
 33 │     )
 34 │     (colemak_enabled)
    ·      ───────┬───────
    ·             ╰── Error here
 35 │   )
    ╰────
  help: string of a known key is expected

        For more info, see the configuration guide or ask
        in GitHub discussions.
            guide : https://github.com/jtroo/kanata/blob/
        main/docs/config.adoc
            ask   : https://github.com/jtroo/kanata/
        discussions

19:00:16 [ERROR] failed to parse file

Describe the solution you'd like
I'd like fork to accept fake keys.

Describe alternatives you've considered
I don't think there are any.

[jtroo]

This could be made possible as-is by changing the code, but I think there are also ways to work around this today.

Instead of XX, in deffakekeys, you could use a key that does nothing like f24, and also use f24 in fork, or use deflocalkeys to make a new key like clmk_en mapped to some nonsense number like 500 in place of f24

[rszyma]

Thanks for help. Although a bit convoluted, this works:

(deflocalkeys-linux
  colemak_enabled 555
)

(deffakekeys
  colemak_enabled_helper colemak_enabled
)

(defalias
  tgl (fork
    (multi
      (layer-switch colemak)
      (on-press-fakekey colemak_enabled_helper press)
    )
    (multi
      (layer-switch qwerty)
      (release-key colemak_enabled)
      (on-press-fakekey colemak_enabled_helper release) 
    )
    (colemak_enabled)
  )
)

---

Update 26.02.2024:

Since toggle was added for fake keys, the above can be simplified to:

(deffakekeys
  fk_colemak (layer-while-held colemak)
)

(defalias
  tgl (on-press-fakekey fk_colemak toggle)
)

[rszyma]

Still, it would be cool to have this feature implemented, just for sake of... completeness 😄

[jtroo]

Implementation notes:

The reason a fake key name doesn't work today in fork's third parameter is that a fake key name doesn't correspond to an output key, but rather an imaginary input key position. E.g. having the following config:

(deffakekeys
  colemak_enabled XX
)

Is somewhat analogous to having:

(defsrc a)
(deflayer base XX)

And then having (fork 1 2 (a)). In this example using a, kanata still allows this config, since a is a real key output, but it wouldn't work in practice, because the physical key wouldn't be outputting the a character anymore.

A potential implementation to get fake key fork working as intended would be to have a fork variant that operates on key coordinates rather than key outputs. It would have to be a variant I think, since this behaviour would not be backwards-compatible with the existing fork behaviour. E.g. with the existing fork behaviour, (fork 1 2 (lctl)) outputs 2 if any physical key or combination of keys were currently outputting lctl. But if the behaviour were to be changed to use key coordinates, only the physical lctl key would cause the outputting of 2, even if the physical lctl were remapped to something else.

[rszyma]

I think I understand the problem here. In other words, if I define a fake key (deffakekeys a XX) and if fork allowed fakekeys (fork 1 2 (a)) there would be a name collision between fake key a and real key a.

[jtroo]

I think I understand the problem here ...

Correct, that would be a problematic consequence of attempting the "trivial" change to allow fake keys in fork.

[jtroo]

This is solved, with virtual/fake key inputs being processable in switch