jtroo
Emacs style prefix key and Own-Layer
I have couple of would-be suggestions or questions, i) is emacs-like chording possible like usage of prefix key C-x C-c ii) can we make any key as modifier/own-layer, the usage is something like this, I hold 3 key and press 4 key to trigger cmd, that changes window screen to three fourth (on assumption the cmd works and does change window screen), even though this can be achieved with tap-hold, it requires layer dedicated for commands in this case '4' or for trigger key '3', is it possible to achieve without any layer, what can be called mini-own-layer for instance with only required keys, so I define like this
(defownsrc 3
4 5
)
(defownlayer 3
@cmd-3-4 @cmd-3-5
)
this way I can have many weird simple layers, without worrying about putting everything together, or managing tens of layers
I attempted this with fake keys,
(defcfg)
(defsrc
grv 1 2 3 4 5
)
(deflayer default
grv 1 2 @s3 4 5
)
(defalias
three 3
)
(deffakekeys
fake_key_3 (macro o k a y S-1)
fake_key_5 (macro o k a y S-1)
)
(defalias
3ld (multi sldr (macro 1 @three))
s3 (tap-hold 150 150 @three @3ld)
)
(defseq
fake_key_3 (3 4)
fake_key_5 (3 5)
)
This does work, but is it right approach ? few issues though i) 3 loses key repeat, and ii) since it is leader style action, I cannot repeat it, for e.g. 3 & 4 without releasing 3 going for 5, will not trigger 3 & 5
Some quick comments:
can we make any key as modifier/own-layer
You may be interested in the discussion in #99 , this seems similar to what you're asking for.
i) 3 loses key repeat
You can get key repeat back by doing a quick press-release-press of the 3 key, though it's not perfect. This is the same behaviour as with QMK's tap-hold and TAPPING_TERM value.
i) is emacs-like chording possible like usage of prefix key C-x C-c
I personally very much dislike emacs style sequences, since in my view it requires too many modifiers and held keys. So I'll likely never implement it myself because in my opinion, it's an inferior input style.
You may be interested in the discussion in #99 , this seems similar to what you're asking for.
I agree it is similar to what I was asking, I feel the syntax I suggested fits in with other regular src/layer definitions, and you could also use the same/similar code to process these mini-layers (in some cases) and one could use chords style to create complex mini layer for e.g.
(defownsrc s-d-f
j k
)
(defownlayer s-d-f
C-M-A-j C-M-A-k
)
i) 3 loses key repeat
You can get key repeat back by doing a quick press-release-press of the
3key, though it's not perfect. This is the same behaviour as with QMK's tap-hold and TAPPING_TERM value.
Fine
i) is emacs-like chording possible like usage of prefix key C-x C-c
I personally very much dislike emacs style sequences, since in my view it requires too many modifiers and held keys. So I'll likely never implement it myself because in my opinion, it's an inferior input style.
I'm a Vim user myself, and my knowledge of Emacs keys are very limited to using Conkeror browser (which is now outdated), and also within Emacs, if I have to use, I know bunch of C-x commands to open, save, close. Still I feel there is a place for Prefix based keyboard chording, apps like Screen, tmux which uses C-b or notion window manager which uses c-k, use it for a reason, mainly when you already have a keyboard based applications running, you need to bypass it somehow, that's when these C-b, C-x, etc prefix commands becomes very useful. Another one from Emacs / Conkeror is window commands, you press C-x then start chaining with 5 and 2 to open new window, on total this is C-x 5 2, while very weird initially, this chaining means no collision with any other shortcuts, and you don't have to press other modifiers after prefix key, you just chain keys individually much like one-shot keys but combined with initial modifier based prefix key and the chaining is unlimited, so easy on your fingers due to not pressing modifiers all the time, no collision, unlimited options
Still I feel there is a place for Prefix based keyboard chording
People have their preferences and things they're used to, and that's very fair.
To summarize my understanding, the benefit that you're describing from emacs-style shortcuts is that they are a mechanism of bypassing the active application key handling mechanisms so that a different app, e.g. tmux/screen/conkeror can handle the sequence instead, which can allow activation of a special, different action. That's a great use case.
For me, kanata already has the mechanisms to achieve the same use case. The mechanism has different activation methods, e.g. tap-hold, or tap-dance, but the end result is the same - a special action happens instead of what the key would normally do in the active application. The way I do most of my special actions in kanata is via home-row tap-hold keys. So for example, if I hold the S key, my I J K L keys become an arrow key cluster.
I'd be ok to accept a PR for emacs-style prefixes for activating special actions so long as it doesn't impede the rest of kanata's functionality. I will likely never implement it myself though, since the existing mechanisms for activating special actions are more comfortable and familiar to me, (and in my biased opinion, are just better 👻).
I agree it is similar to what I was asking, I feel the syntax I suggested fits in with other regular src/layer definitions, and you could also use the same/similar code to process these mini-layers (in some cases) and one could use chords style to create complex mini layer for e.g.
From an implementation standpoint it's unclear how your suggestion would be done. It's not obvious how it would fit into the underlying keyberon library's state machine.
Also, somewhat related, I would suggest not being too worried about defining multiple, mostly-empty layers. I do that in my own configuration. Maybe you're already reaching the current limit of 25, which could be the issue. You can easily change that limit in the code and compile it yourself though. The program will mostly just use up more memory, there likely won't be much performance penalty (though I haven't done the testing to truly validate this).
https://github.com/jtroo/kanata/blob/4804012b5cf96d8f337141c20a0172ecb3a5d595/src/layers.rs#L10
I didn't understand your example. But all of this is trivial in Kanata. Prefix keys/leader keys should be easy to create in Kanata.
I have not gotten there yet because I use Emacs, so it takes care of that for me. AHK also handles that. But I'm sure I'll get there. For now, I will actually work on getting rid of the holy ones, C-c <letter>, the ones reserved for users by putting them on my ring finger. Hold ring finger and hit k will send C-c k. Hold ring finger and hit a will send C-c a.
I think prefix/leader keys are great when a keybind space is super heavy or the output keys all follow a pattern, like the A-', A-<backtick>, and A-~ keys in Emacs (to make è, á, ñ, et cetera glyphs). But, yeah, unless I'm missing something very obvious, super easy in Kanata.
pseudo code:
tap-hold x diacritic-layer
one-shot acute-layer [mapped to ']
one-shot grave-layer
one-shot tilde-layer
á key on acute-layer
hold x
tap ' [which is a one shot to the acute-layer]
release all keys
tap a [get á]
[profit from the magic of prefix keys]
correct me if I'm mistaken.
