What if you could eliminate that switching cost? What if switching apps, rather than forcing you to learn new shortcuts, instead reinforced your muscle memory for the shortcuts you already know? In short, what if all of your apps felt the same? So, what happens when you try out a new app, and its keyboard shortcuts don’t align with your muscle memory? You could work on memorizing a whole new set of shortcuts, but then you face a cost of switching every time you change apps. You've likely memorized many of the shortcuts of your most used apps and, somewhere during this process, repetition has given way to muscle memory, making these shortcuts feel like second nature. But you're probably also aware that most of the apps you use on a daily basis provide keyboard shortcuts to increase the efficiency of routine tasks. You likely use a combination of your mouse and keyboard to interact with your computer throughout the day. There's a few features in there now that I am not covering in this post, but we'll get to them later in this series.If you’re reading this, odds are you work on a computer. It's possible it's gone through new versions since this post. If you want to read a at the time of this blog post, it's available on my GitHub. No more discovering that weird app behavior is due to a double-bound keybinding.Īs this series continues, I'll list the examples of how I connect a to other automations here. All my keybindings are declared in one place, and I know they will never conflict with any new applications that I download. I use a as the "entry point" for nearly all my Hammerspoon based automation. My most common use of a is to launch an application, so I have a table of applications that I can define a "hyper key" for, and optionally some local bindings that I bind inside that application to use globally. hyper : bind (, 'r', nil, function () hs. Press `HYPER+r`, get the Hammerspoon console. Because your "hyper key" is not a cluster of modifier keys, you can actually use it in conjunction with any normal modifiers. One big advantage to using Hammerspoon as a "man-in-the-middle" is using modifiers with your hyper key. Brett Terpstra first wrote about this in "A Useful Caps Lock Key" in 2012. In this as in all things, I am not the first. Instead of having every single application listening to all the keystrokes, I can control it one place. I use a single often-unused key (in my case, F19) to trigger a hs.hotkey.modal in Hammerspoon. In my case, Hammerspoon becomes a single "router" to all the automation and UI customization on my Mac. Using a single keycode as your "hyper" key, and handling the translation at the automation layer is much more expressive. Because of this a lot of hyper key setups are limited to "leader key" style interactions. Using the "hyper chord" as the entire "hyper key", you can't add any more modifiers, because it is already all the modifiers. While it works well, it has its limitations. You can absolutely do this in Hammerspoon if you want. The user would then use some kind of automation software like Alfred or Keyboard Maestro to listen for the "hyper chord" and fire different automations.
Traditionally, a Hyper key is implemented by sending to the Operating System "hyper chord" of ⌘⌥⇧⌃ by modifying the keyboard firmware or using Karabiner-elements.app. The code isn't that complex so this post will be focused on the advantages of this approach. I'm using hs.hotkey.modal to capture an F19 keystroke, and only sending the "hyper chord" of ⌘⌥⇧⌃ if absolutely required. At the moment, my hyper implementation is contained in a lua module called a, with some dependencies on Karabiner-Elements.app. I talked in the last post about my history with the concept, how I learned from Steve Losh's post on the topic and borrowed from Brett Terpstra… and I've expanded the idea a bit.
0 kommentar(er)
