Potential internal restructuring

[koekeishiya]

I have had the following thoughts for some time now, and am debating whether I should do the changes listed below:

• Implement support to differentiate between commands that run on key-down, repeat, and release events.
• Implement mouse-down, up events.
• Add IPC mechanism to query current state and/or all state. This includes current available hotkeys (based on the active mode), or all modes with the hotkeys they provide. Probably json output for best integration with external tools.
• Utilize above IPC mechanism to synthesize hotkeys so that we don't need to take the overhead of process startup to simply synthesize a key. This will also allow the option to pass some kind of flag that makes skhd not capture the event it posted, so that key-remapping becomes more feasible than it currently is.
• I want to revise the syntax used to define hotkeys.

This might end up with me just starting from scratch and replacing the current files in the repo with a new version, eventually, as the planned changes pretty much call for a complete rewrite. The plan is to persist all current features somehow, but the syntax is probably going to be somewhat different.

[MuhammedZakir]

A more compact syntax similar to 'sxhkd' [1] would be great to reduce clutter!

[1] https://github.com/baskerville/sxhkd#example-bindings

[nikhgupta]

I know this might not make it to the top of your priority list, but a way to display a "cheat-sheet" for available commands would be great. It will serve a few purposes:

• help everyone in remembering skhd keybindings
• adopting skhd keybindings from someone else will become easier as you can quickly see what keybindings are available
• more importantly, for people using modals - it will help them know which modal state they are in. This has been a real issue for me (and the only one with skhd). I use modals heavily (vim-like modal keybindings workflow #152) and oftentimes, I am not sure what modal state I am in.

[jasonpott]

I have only just started using skhd but being able to capture mouse button key presses and pass commands within apps would allow me to replace btt which i routinely have problems with.

[AlgusDark]

I know this might not make it to the top of your priority list, but a way to display a "cheat-sheet" for available commands would be great. It will serve a few purposes:

• help everyone in remembering skhd keybindings
• adopting skhd keybindings from someone else will become easier as you can quickly see what keybindings are available
• more importantly, for people using modals - it will help them know which modal state they are in. This has been a real issue for me (and the only one with skhd). I use modals heavily (vim-like modal keybindings workflow #152) and oftentimes, I am not sure what modal state I am in.

I had the same need and I ended up creating a small which-key with hammerspoon for that:
https://www.youtube.com/live/UchF6s2j5r8?feature=share&t=2273

[koekeishiya]

Well a potential internal restructuring didn't happen, but instead there will be something else:
https://github.com/koekeishiya/meraki/blob/master/examples/merakirc

This is not aiming for feature parity with skhd or anything like that, which is why it is a separate project.
I am not really interested in input, but I am just linking it here in case the end goal might be interesting.
The reference specification is more or less a complete description of how things will work.