-
Notifications
You must be signed in to change notification settings - Fork 231
implement key and modifier alias #288
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
After some looking-around, it seems like this repo is not actively accepting changes and PRs. I've decided to close this PR and create a new fork to experiment with some more new feature ideas (which might break compatibility, that's why I'm forking.) Some more highly requested features here might also be "stolen" and implemented on that fork, I hope you wouldn't mind that. I see the new fork as a more evolving version of skhd, with new (incompatible) config syntaxes & semantics and more features. And the original version of skhd can keep being the more stable and compatible alternative for users who don't want to switch and rewrite their config. This way, we can take away the heavy lifting of supporting skhd and adding new features from you, without breaking anything for old users. Thanks for your great work on skhd! |
|
I am extremely interested in this. Can you link to the fork? Thank you for your work on this @Miigon :) |
|
Update: Redesigned a large portion of the parsing procedures and added new features (aliases, layers, keydown/keyup binding, builtin key synthesizing with non-recursive support, etc) Some features are not yet finalized and many are yet to come. the syntax and semantics are not final either. The only document right now is an example configuration. Take a look and let me know what you think. The short-term plan is to add highly requested features from skhd issues, then finalize the syntaxes and documentation before releasing the first version. |
|
I don't mind what you are doing, but I personally do not think this codebase is worth iterating on. It is better to start from scratch, and if you need to know how some specific macOS things work, look at how it was done here for inspiration as the documentation for said APIs are rather lackluster. |
|
Did it get merged? Bit confused, as I tried it out and got At the moment I'm using a rather convoluted script that does a @Miigon really tempted by your fork but it looks a little inactive? And no homebrew formula. But I get it, a fork is a lot to take on :) If there's a better way to do it with the new skhd? basically i rely heavily on ... |
Implements key aliases feature allowing users to define reusable names for modifiers, keys, and key combinations, making configs more readable and maintainable. Features: - Three alias types: modifier, key, and keysym - Full recursive expansion at parse time (zero runtime overhead) - Circular reference detection with helpful error messages - Nested alias support (aliases can reference other aliases) - Compatible with existing syntax (modifiers combine like hyper/meh) Syntax: .alias $super cmd + alt # Modifier alias .alias $grave 0x32 # Key alias .alias $nav_left $super - h # Keysym alias Usage: $super - t : command # Use modifier alias ctrl - $grave : command # Use key alias $nav_left : command # Use keysym standalone ctrl + $nav_left : command # Add modifiers to keysym Implementation: - Tokenizer: Added Token_Alias for $identifier syntax - Parser: Added Alias union type with storage and resolution logic - Comprehensive error messages for type mismatches and undefined aliases - Full test coverage for all alias types and error cases - Documentation in SYNTAX.md and README.md with examples Inspired by asmvik/skhd#288
Fixes #174 #6 #280 #226 #194
looks like this:
Simplifying keymaps with eg.
hyperkeys. Easier to manage configuration.This PR also:
parse_hotkeyandparse_keypress.)skhd -kexit with -1 when failed to parse.skhd --verbose -krespect--verbose(do not close stdout/stderr when in verbose)This new feature technically deprecates some keycode literals like
mehandhyper, however they're still kept for backward compatibility.