Open Dregu opened 10 months ago
just fyi, I'm tracking your activity with some interest, could be a useful feature and solve the issue of auto-repeating keys being translated from "vvv^" to "v^v^v^". I've attempted it once, but didn't find an easy solution. I don't have the time now to really dig into it and understand what exactly you're doing and how. Can't make any promises if I will ever merge this. Generally speaking, it would help if you make the whole thing easier, rather than more complex (I need to stay in control of what's happening in the code), and if you don't add specific functions for special cases where one general function could cover it.
Yeah well just like you probably, I'm mainly doing this for me, but putting it out there cause I know it will help someone else too.
The latest commits should definitely make the whole thing more simple by unifying the combo formats and removing restrictions, but there are also cases where key() behavior is still preferred to hold(), so I'm not going to simplify it too much by getting rid of all the choices. Also tried not to make any breaking changes to old configs, but that said I think most of these simple one-to-one mappings using key() should definitely switch to hold(), it just acts more natural and doesn't glitch with key repeat.
Heh, this PR got out of hand really fast, but I kept finding more things that weren't possible. I completely understand if you never want to merge this mess, but maybe it gives you some ideas of what kind of functionality is missing. And people can still use this fork if they need these things too.
Looks like I really set out to fix every single thing that annoys me with my keyboard/shortcuts. I know adding stuff like exec() might be outside the scope of this project, but it's really the only solution to all these games eating inputs that they have no business eating, even from autohotkey.
Not even recommending this to be merged any more, everything is very untested and undocumented, and I keep finding little problems here and there, but I'll also keep fixing those problems.
Do what you want, but I'd keep this PR up for the people.
TL;DR: This PR really just fixes a ton of gripes I have with my own keyboard, but also adds many requested features like momentary/toggleable layers, holding keys properly, many new trigger types and the list goes on.
I've been using capsicain to emulate the Fn layer on various budget 65% keebs with completely different Fn layers, which was super annoying. Another annoying thing these boards do with Fn is, when you release Fn before the other key, like a quick Fn+(F)2 to rename a file, it switches the output too early and renames the file "2". Capsicain didn't help with that issue much, cause
key()
is behaving the same way, only after repeat delay.hold(key)
function will keepkey
held for as long as the original key is held, without the repeat v^v^ flicker thatkey()
hasmoddedhold()
will release all keys before holding the combo, likemoddedkey()
(but not re-press them on release)holdmods()
will hold modifiers separately with physical modifier, and other keys with physical keymoddedhold()
tries to release them, the release is blockedhold()
will only translate repeat events to the last key in the combo, as is standard behavior. This can be changed withOPTION HoldRepeatsAllKeys
key(combo, type)
can be used as an alias for different functions, cause these function names are getting stupid, see exampleA + ..&& + LWIN + X
*
will trigger on TapAndHold, but doesn't need a TapAndHold rewire/
will trigger on tap OR hold, but doesn't need two separate COMBOs fort
and&
DOWN, UP, TAP, SLOW
combo triggers,down(), up(), toggle(), tap(), uptap()
functions allow toggleable layersexe()
launches programs without AHK, when it would be blocked, or you don't want to send any keys to userspace to do thatThis fixes #39, fixes #56, fixes #83, fixes #85, fixes #98, fixes #102.
The release is updated on my fork if you want to test how
hold()
is superior tokey()
.