Hammerspoon – macOS automation with Lua(hammerspoon.org)
hammerspoon.org
Hammerspoon – macOS automation with Lua
https://www.hammerspoon.org/
93 comments
I update my Slack status to "home|work" based on what wifi my laptop gets connected.
how do you do it, can you share your config
[deleted]
Wow, 1 and 3 are things I've really been wanting but didn't realize hammerspoon could do, thanks!
I'm already using hammerspoon for making scrolling work with my trackball mouse and it works great.
I'm already using hammerspoon for making scrolling work with my trackball mouse and it works great.
I have a Kensington trackball and scrolling works fine with provided drivers or even without them. Just curious about hammerspoon was needed in your case.
i’m not OP, but some older design trackballs still being sold don’t have scroll. Also, some newer designs have poor scrolling due to physical scroll ring not being smooth, or the touch scrolling being jittery. But, yes i would like to hear what his hammerspoon solution is too.
Hammerspoon is one of my favorite tools. I especially like the low latency of the system hooks, other tools like Automator or Folder Actions have a couple second delay betweeen the trigger and the action. Hammerspoon is pretty much instant.
On top of that, Hammerspoon is very actively developed and the maintainers are super knowledgeable and responsive.
I've shared a couple scripts on here before, like Anycomplete (Google autocomplete anywhere): https://news.ycombinator.com/item?id=13065670
On top of that, Hammerspoon is very actively developed and the maintainers are super knowledgeable and responsive.
I've shared a couple scripts on here before, like Anycomplete (Google autocomplete anywhere): https://news.ycombinator.com/item?id=13065670
It is a truly great tool. The caveat is that using Hammerspoon is essentially programming. So it is "only" suitable for technical users like developers.
For the casual Mac user (e. g. product manager or the guy from sales) the visual Sikuli or UI.Vision RPA tools are more suitable for creating automation scripts.
For the casual Mac user (e. g. product manager or the guy from sales) the visual Sikuli or UI.Vision RPA tools are more suitable for creating automation scripts.
I mean, macOS already has built in automation (with Automator) that you can write in AppleScript or JavaScript JXA. https://github.com/JXA-Cookbook/JXA-Cookbook is not very updated but its wiki contains quite a bit of useful recipes.
Why would I prefer this over the built in option?
Why would I prefer this over the built in option?
Hammerspoon is suited for tasks that keep working in the background. Plus it has access to stuff like arbitrary drawing on the screen, which AppleScript doesn't provide. The most used case is custom bindings for (almost) arbitrary hotkeys.
Automator/AppleScript are sufficient when you only need their standard hook points―services and such.
Btw, JXA is a big disappointment: it maps Objective-C/AppleScript's calls and especially structures very awkwardly instead of providing more JS-native experience. And afaik its official documentation is lacking.
Automator/AppleScript are sufficient when you only need their standard hook points―services and such.
Btw, JXA is a big disappointment: it maps Objective-C/AppleScript's calls and especially structures very awkwardly instead of providing more JS-native experience. And afaik its official documentation is lacking.
AppleScript is awful to write and JXA is impossible to find documentation for.
One trick to finding JXA documentation is simply to look at the AppleScript documentation and translate the code to JavaScript syntax, or, depending on what you've doing, look at the Objective-C Cocoa documentation and translate the syntax.
For example, to obtain the current date and one day from now, in Objective-C you might write:
For example, to obtain the current date and one day from now, in Objective-C you might write:
NSDate *now = [NSDate date];
NSDate *tmr = [date dateByAddingTimeInterval: 86400];
var now = $.NSDate.date;
var tmr = now.dateByAddingTimeInterval(86400);> look at the AppleScript documentation and translate the code to JavaScript syntax
Yeah, I can’t do this. It’s non-obvious to me how it translates until I actually stumble upon the correct thing.
Yeah, I can’t do this. It’s non-obvious to me how it translates until I actually stumble upon the correct thing.
AppleScript looks fantastically simple and easy to pick up until you actually come to write some. Then, because of the "conversational" structure of it, it feels more like guessing the right magic incantation than programming.
It certainly reads nicer to non-programmers, but I feel like writing it requires just as much learning as any more "traditional" scripting language, so I'm not really sure what the benefit is.
It certainly reads nicer to non-programmers, but I feel like writing it requires just as much learning as any more "traditional" scripting language, so I'm not really sure what the benefit is.
I'm more of a hobbyist than a professional programmer, so take that for what you will:
I really like Applescript. I agree that it's harder to write, and especially harder to write well, because functional Applescript won't necessarily come out as english sentences, if you aren't careful to construct it the right way.
But the enhanced readability makes it worthwhile. I love that I can look at my own Applescript code and just read what it's doing in english.
I actually wish I could do more with Applescript than just Mac scripting. I've been thinking for a few years now that I ought to play around with Hypercard, but PowerPC emulators are a pain to get running. There's a modern clone called SuperCard, but it costs $200...
P.S. The "open dictionary" option built into the Script Editor is helpful for finding the right "incantation".
I really like Applescript. I agree that it's harder to write, and especially harder to write well, because functional Applescript won't necessarily come out as english sentences, if you aren't careful to construct it the right way.
But the enhanced readability makes it worthwhile. I love that I can look at my own Applescript code and just read what it's doing in english.
I actually wish I could do more with Applescript than just Mac scripting. I've been thinking for a few years now that I ought to play around with Hypercard, but PowerPC emulators are a pain to get running. There's a modern clone called SuperCard, but it costs $200...
P.S. The "open dictionary" option built into the Script Editor is helpful for finding the right "incantation".
LiveCode is the modern (and vastly more powerful) version of HyperCard, and it has a free community version: https://livecode.com/
I think it requires more. I have a deep respect for anyone who can figure out how to write AppleScript, because I sure haven’t figured it out even after being able to pick up most “traditional” scripting languages quite quickly.
So, inverse APL?
Read-only, write-never?
;)
Read-only, write-never?
;)
Funny enough, back when the Mac Automation devs were still getting JXA ready to throw away, one of the things I told Sal Soghoian to do was to add automatic AS-to-JS syntax translation to Script Editor’s Log pane. While it only translates outgoing Apple events, not native AS code, 99% of the time JS users already know how to write general JS code, and it’s the application-specific references and commands they’re struggling to form.
Back when appscript was still a thing I hacked together a quick-n-dirty AppleScript-command-to-Python/Ruby/ObjC translator app which appscript users absolutely adored, plus it greatly reduced the number of “How do I…” support questions because, more often than not, users already had a working example in AppleScript which they could just run through the translator to get the answer for themselves.
Needless to say, Sal Soghoian completely ignored my expert recommendation for this killer feature which could be implemented in a day, choosing instead to dump JXA and its few hapless users down the same black hole of nothingness as all his other product failures. PEBKAC. Not Invented Here. So it goes.
--
[edited to add]
Just d/led the JavaScriptOSA zip from the appscript project page on SourceForge, and the bundled JABDemo.app still works. It’s not codesigned so you’ll have to right-click the app to Open it, overriding the security warnings, but it still works even on 10.15 (caveat any bugs in the underlying JavaScript Apple event bridge, of which there were a few, plus the endless string of permission requests whenever you try to control another app). Example:
Original AppleScript commands:
Back when appscript was still a thing I hacked together a quick-n-dirty AppleScript-command-to-Python/Ruby/ObjC translator app which appscript users absolutely adored, plus it greatly reduced the number of “How do I…” support questions because, more often than not, users already had a working example in AppleScript which they could just run through the translator to get the answer for themselves.
Needless to say, Sal Soghoian completely ignored my expert recommendation for this killer feature which could be implemented in a day, choosing instead to dump JXA and its few hapless users down the same black hole of nothingness as all his other product failures. PEBKAC. Not Invented Here. So it goes.
--
[edited to add]
Just d/led the JavaScriptOSA zip from the appscript project page on SourceForge, and the bundled JABDemo.app still works. It’s not codesigned so you’ll have to right-click the app to Open it, overriding the security warnings, but it still works even on 10.15 (caveat any bugs in the underlying JavaScript Apple event bridge, of which there were a few, plus the endless string of permission requests whenever you try to control another app). Example:
Original AppleScript commands:
tell app "textedit" to get name of document 1
tell app "finder" to count every folder of home whose name begins with "D"
app("TextEdit").documents.at(1).name.get()
app("Finder").home.folders.where(its.name.beginsWith("D")).count({each: k.item})
You can use TypeScript to improve the tooling: https://github.com/JXA-userland/JXA
Huh, interesting. I’ll have to see if I can get the autocompletion bits to work–I’m not sure I need the other stuff it offers.
That's a strategy to guess code but it doesn't yield documentation.
And there's Fennel - an Lisp that compiles to Lua which makes writing Spoons (Hammerspoon plugins) pure joy.
https://fennel-lang.org/
https://fennel-lang.org/
If you like Fennel, you're gonna like Spacehammer - Spacemacs inspired Hammerspoon config written in Fennel.
https://github.com/agzam/spacehammer
Thanks, I'll take a look.
I'm already using MenuHammer[1] (menu system inspired by Spacemacs) and Spectacle.
But plan for a next year or two is to build custom ergo keyboard (r/ErgoMechKeyboards has a bunch of interesting stuff - I'm aiming for Corne or Iris) and then to customize keyboard layout + Hammerspoon to reduce mouse usage as much as possible. With various VIM plugins available for editors and Firefox (Tridactyl) I'm quite optimistic.
[1] https://github.com/FryJay/MenuHammer
I'm already using MenuHammer[1] (menu system inspired by Spacemacs) and Spectacle.
But plan for a next year or two is to build custom ergo keyboard (r/ErgoMechKeyboards has a bunch of interesting stuff - I'm aiming for Corne or Iris) and then to customize keyboard layout + Hammerspoon to reduce mouse usage as much as possible. With various VIM plugins available for editors and Firefox (Tridactyl) I'm quite optimistic.
[1] https://github.com/FryJay/MenuHammer
"...impossible to find documentation for"
Exactly. It's been years since first released and nothing is really out there to tell you how to use it. I wish they would finish it up as it is much better that AppleScript.
Exactly. It's been years since first released and nothing is really out there to tell you how to use it. I wish they would finish it up as it is much better that AppleScript.
That will never happen. JXA is junk, same as Scripting Bridge before it; and they never shit to fix SB even when they had years to do it. There’s a reason Apple finally disbanded the Mac Automation team and fired the PM responsible. JXA should’ve saved Mac Automation, but it killed it instead.
Worst part is: it should never have come to this.
(For those that don’t know, I am the world expert at building production-ready Apple event bridges, with half-a-dozen under my belt. Outside of myself, Dave Winer’s Userland, and the original AppleScript creators, no-one else on the planet has ever managed this.)
Immediately after JXA was surprised-announced at WWDC14, I dropped everything else, reached out to Sal Soghoian (Mac Automation PM), and crash-coursed six weeks of testing and critiquing JXA, up to and including writing a nearly-complete “JavaScriptOSA” reference implementation for the JXA devs to learn from, or just outright steal.
Even rushed and unfinished, JavaScriptOSA showed what JXA should’ve been. And they had double the developers, all the AppleScript source and internal Apple documentation, and a year. You can d/l it here:
https://sourceforge.net/projects/appscript/files/JavaScriptO...
While the Xcode project is far too old to build now and some of that code is a lashup of which I’m not proud, the prebuilt component may still work in Script Editor (though I’ve not tested it in years), as should the standalone “demo” app I bundled with it.
Bear in mind, my JavaScriptOSA implementation[1] was based on my previous appscript work [2], which had alrady proven itself a genuine AppleScript replacement years earlier. Apple even considered including Python and Ruby appscript in Mac OS X Leopard, so it’s not like my code wasn’t already known about, read, or used by folks within Apple. But the Mac Automation team still thought they knew better than a production-proven solution that had at its height a couple thousand extremely happy users, whereas their own previous attempt had only proven an embarrassing failure.
I didn’t get so much as a thanks-but-no-thanks; 200+ work hours straight down the crapper. And JXA shipped half-baked and broken, and immediately abandoned to sink without trace. I scrapped my plan to write the book on Automating your Mac with JavaScript, because you can’t write really good books about really lame broken technology, at least not without losing your mind. (I should know: I lead-authored one of the last AppleScript books.) Apple’s last, best chance to turn Mac Automation around, pissed up the wall and forgotten just as fast.
Honestly, Apple’s real mistake was not firing that preening incompetent, Sal Soghoian, years sooner, while there was still something worth saving.
..
Okay, so with hindsight, JXA was never likely to succeed, even if they had done its implementation and marketing right. As an OSA language component, it lives in its own little closed world, completely separate to Node.js and its vast npm ecosystem. Even in 2014 Node was already killing it in the JS-on-server-and-desktop wars, but instead of “Embrace and Extend” JXA chose “Not Invented Here” instead.
Worse, JXA is built on OSA which is a ComponentManager technology; a hideously ancient, inherently insecure, and long-deprecated in-process plugin architecture. Thus the JXA implementation was already obsolete even before it shipped. A straight port of node and npm CLI tools onto JavaScriptCore with a V8 API compatibility layer for C-based extensions would have been the right choice. But the Mac Automation team didn’t see, because like their technologies they exist in a closed little world completely isolated from everything and everyone else.
One More Thing: Around the same time as Sal was getting his ass ejected from Apple, I wrote one more Apple event bridge, nodeautomation, just to prove my point that creating a competent AppleScript alternative for a massively popular, developer-friendly language is both quickly and easily achievable, so Sal’s team had absolutely no excuse for fucking it up twice.[3] Although it looks like recent macOS/Node updates have broken the build (again), so you’d need to run it on an older platform if you wanted to play with it.
I can still vouch for Python3-appscript, as that’s what I use myself, but I no longer provide support for any of them because as much as I love Apple event automation and the incredible solutions it makes easy to build, even I accept it has been utterly buggered to death now, and the only question remaining is how much longer till Apple finally put it out our misery for good.
..
That said, if any Hammerspoon fans wish to cross my palm with silver, I’ve previously offered to do a Lua-Apple event bridge for it, and would be happy to do so even now. (Misery loves company.:)
--
[1] No relation to Late Night Software’s original JavaScriptOSA, which like JXA was also riddled with flaws and never went anywhere.
[2] http://appscript.sourceforge.net/
[3] Or thrice, if you count the time after the JXA fiasco that I offered to give Sal my SwiftAutomation bridge [4] outright, just as Swift was starting its meteoric rise, and he threw it back in my face. I’ve dealt with some stupid PMs over the years, but Jebus that one was dumber’n all those other stumps put together. What a waste.
[4] https://hhas.bitbucket.io/
Worst part is: it should never have come to this.
(For those that don’t know, I am the world expert at building production-ready Apple event bridges, with half-a-dozen under my belt. Outside of myself, Dave Winer’s Userland, and the original AppleScript creators, no-one else on the planet has ever managed this.)
Immediately after JXA was surprised-announced at WWDC14, I dropped everything else, reached out to Sal Soghoian (Mac Automation PM), and crash-coursed six weeks of testing and critiquing JXA, up to and including writing a nearly-complete “JavaScriptOSA” reference implementation for the JXA devs to learn from, or just outright steal.
Even rushed and unfinished, JavaScriptOSA showed what JXA should’ve been. And they had double the developers, all the AppleScript source and internal Apple documentation, and a year. You can d/l it here:
https://sourceforge.net/projects/appscript/files/JavaScriptO...
While the Xcode project is far too old to build now and some of that code is a lashup of which I’m not proud, the prebuilt component may still work in Script Editor (though I’ve not tested it in years), as should the standalone “demo” app I bundled with it.
Bear in mind, my JavaScriptOSA implementation[1] was based on my previous appscript work [2], which had alrady proven itself a genuine AppleScript replacement years earlier. Apple even considered including Python and Ruby appscript in Mac OS X Leopard, so it’s not like my code wasn’t already known about, read, or used by folks within Apple. But the Mac Automation team still thought they knew better than a production-proven solution that had at its height a couple thousand extremely happy users, whereas their own previous attempt had only proven an embarrassing failure.
I didn’t get so much as a thanks-but-no-thanks; 200+ work hours straight down the crapper. And JXA shipped half-baked and broken, and immediately abandoned to sink without trace. I scrapped my plan to write the book on Automating your Mac with JavaScript, because you can’t write really good books about really lame broken technology, at least not without losing your mind. (I should know: I lead-authored one of the last AppleScript books.) Apple’s last, best chance to turn Mac Automation around, pissed up the wall and forgotten just as fast.
Honestly, Apple’s real mistake was not firing that preening incompetent, Sal Soghoian, years sooner, while there was still something worth saving.
..
Okay, so with hindsight, JXA was never likely to succeed, even if they had done its implementation and marketing right. As an OSA language component, it lives in its own little closed world, completely separate to Node.js and its vast npm ecosystem. Even in 2014 Node was already killing it in the JS-on-server-and-desktop wars, but instead of “Embrace and Extend” JXA chose “Not Invented Here” instead.
Worse, JXA is built on OSA which is a ComponentManager technology; a hideously ancient, inherently insecure, and long-deprecated in-process plugin architecture. Thus the JXA implementation was already obsolete even before it shipped. A straight port of node and npm CLI tools onto JavaScriptCore with a V8 API compatibility layer for C-based extensions would have been the right choice. But the Mac Automation team didn’t see, because like their technologies they exist in a closed little world completely isolated from everything and everyone else.
One More Thing: Around the same time as Sal was getting his ass ejected from Apple, I wrote one more Apple event bridge, nodeautomation, just to prove my point that creating a competent AppleScript alternative for a massively popular, developer-friendly language is both quickly and easily achievable, so Sal’s team had absolutely no excuse for fucking it up twice.[3] Although it looks like recent macOS/Node updates have broken the build (again), so you’d need to run it on an older platform if you wanted to play with it.
I can still vouch for Python3-appscript, as that’s what I use myself, but I no longer provide support for any of them because as much as I love Apple event automation and the incredible solutions it makes easy to build, even I accept it has been utterly buggered to death now, and the only question remaining is how much longer till Apple finally put it out our misery for good.
..
That said, if any Hammerspoon fans wish to cross my palm with silver, I’ve previously offered to do a Lua-Apple event bridge for it, and would be happy to do so even now. (Misery loves company.:)
--
[1] No relation to Late Night Software’s original JavaScriptOSA, which like JXA was also riddled with flaws and never went anywhere.
[2] http://appscript.sourceforge.net/
[3] Or thrice, if you count the time after the JXA fiasco that I offered to give Sal my SwiftAutomation bridge [4] outright, just as Swift was starting its meteoric rise, and he threw it back in my face. I’ve dealt with some stupid PMs over the years, but Jebus that one was dumber’n all those other stumps put together. What a waste.
[4] https://hhas.bitbucket.io/
Applescript seems to have been a mistake in that it is too irregular and programmers don't learn and use it. I researched the most highly thought of books on Applescript and even they were emphasizing how hard it was to know thoroughly.
Key insight: Apple event IPC is not OOP, it is RPC + simple first-class queries. It is far more closely related to SQL and relational databases than to DOM.
Unfortunately, programmers look at AppleScript syntax, which is superficially OO-like, and assume it is OOP. Which causes huge confusion and frustration when it behaves in completely non-OO ways.
The confusion is confounded by AppleScript’s fondness for “magical” behaviors—including overloading native language operators and automatically dispatching remote calls (aka “implicit gets”) without obvious rhyme or reason—plus enough syntactic sugar to rot anyone’s brain to mush.
Ironically, non-programmers don’t struggle nearly so much because they are operating on simple ignorance rather than outright misunderstanding, so they accept what it’s doing on face value, rather than trying to map everything they see onto completely the wrong mental model and getting utterly honked that prediction and observation refuse to match up.
In fact there are hard rules behind all of AS’s behavior, but they are utterly opaque and never adequately explained anywhere, so are largely indistinguishable from “What the F* is Going On?”. Hell, I rewrote most of the early chapters for the last edition of Apress’s AppleScript book, and even I bottled it as “too hard to explain to anyone else”.
..
Things might’ve turned out differently had AppleScript’s original designers not quit in disgust at Apple [mis]management shortly after AppleScript 1.1 went out, but when they walked out much of the expert insight and knowledge went with them, not to mention the ability to fix it once users’ feedback was pointing all its flaws out. But “coulda, woulda, shoulda” is the Mac Automation story throughout (my own failed contributions included).
Dr William Cook’s paper on the early history of AppleScript and its design and ambitions is well worth a read:
http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf
Unfortunately, programmers look at AppleScript syntax, which is superficially OO-like, and assume it is OOP. Which causes huge confusion and frustration when it behaves in completely non-OO ways.
The confusion is confounded by AppleScript’s fondness for “magical” behaviors—including overloading native language operators and automatically dispatching remote calls (aka “implicit gets”) without obvious rhyme or reason—plus enough syntactic sugar to rot anyone’s brain to mush.
Ironically, non-programmers don’t struggle nearly so much because they are operating on simple ignorance rather than outright misunderstanding, so they accept what it’s doing on face value, rather than trying to map everything they see onto completely the wrong mental model and getting utterly honked that prediction and observation refuse to match up.
In fact there are hard rules behind all of AS’s behavior, but they are utterly opaque and never adequately explained anywhere, so are largely indistinguishable from “What the F* is Going On?”. Hell, I rewrote most of the early chapters for the last edition of Apress’s AppleScript book, and even I bottled it as “too hard to explain to anyone else”.
..
Things might’ve turned out differently had AppleScript’s original designers not quit in disgust at Apple [mis]management shortly after AppleScript 1.1 went out, but when they walked out much of the expert insight and knowledge went with them, not to mention the ability to fix it once users’ feedback was pointing all its flaws out. But “coulda, woulda, shoulda” is the Mac Automation story throughout (my own failed contributions included).
Dr William Cook’s paper on the early history of AppleScript and its design and ambitions is well worth a read:
http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf
Thanks for the link! Best explanation of Apple Events I’ve ever seen, plus interesting to read a first-hand account of AppleScript’s history.
Yeah, it’s a great, incredibly insightful paper, written by one of AppleScript’s original designers.
It’s only a pity it wasn’t published a decade earlier, back when classic Mac OS developers were attempting to build Apple event bridges for languages like Perl, Python, and JavaScript. All of those popular programmer-friendly languages had their own native Apple event bridges from very early on. And all of those bridges sucked.
Not because they’re technically hard to write, but because no-one ever explained how.
And since (with the exception of Perl and Frontier) all those third-party devs were coming at the problem from a strongly OOP background, they all promptyl fell into the ORM trap: trying to make Apple events behave like the host language’s native OO, instead of vice-versa. ’Cos if you think creating an Object-Relational Mapper over half-a-dozen similiar SQL-speaking RDBMSes results in a crippled dumbed-down API that fights you more than it helps, imagine trying to create one that works fully and correctly over hundreds of wildly differing targets with no common dialect at all.
(Perl’s Mac::Glue did avoid the ORM trap, but—being Perl—ran into impedance mismatches of its own. Only Frontier got it more or less right… right in time for Dave Winer to throw his toys out the pram and sulk off.)
Thus AppleScript never won because it was good. It won because all of its alternatives were even worse.
Even the first Python appscript, which I wrote way back in 2003, was a stinker; although it did get better eventually (after I threw it out and redesigned and rewrote it from scratch). Bloodly lovely bit of kit in the end, never equalled before or since—and I say that as its most rabidly demanding and intolerant user.:) Still kicking myself for blowing the one chance to get it bundled in Mac OS X itself; Apple Automation would be in a very different place today if it had.
It’s only a pity it wasn’t published a decade earlier, back when classic Mac OS developers were attempting to build Apple event bridges for languages like Perl, Python, and JavaScript. All of those popular programmer-friendly languages had their own native Apple event bridges from very early on. And all of those bridges sucked.
Not because they’re technically hard to write, but because no-one ever explained how.
And since (with the exception of Perl and Frontier) all those third-party devs were coming at the problem from a strongly OOP background, they all promptyl fell into the ORM trap: trying to make Apple events behave like the host language’s native OO, instead of vice-versa. ’Cos if you think creating an Object-Relational Mapper over half-a-dozen similiar SQL-speaking RDBMSes results in a crippled dumbed-down API that fights you more than it helps, imagine trying to create one that works fully and correctly over hundreds of wildly differing targets with no common dialect at all.
(Perl’s Mac::Glue did avoid the ORM trap, but—being Perl—ran into impedance mismatches of its own. Only Frontier got it more or less right… right in time for Dave Winer to throw his toys out the pram and sulk off.)
Thus AppleScript never won because it was good. It won because all of its alternatives were even worse.
Even the first Python appscript, which I wrote way back in 2003, was a stinker; although it did get better eventually (after I threw it out and redesigned and rewrote it from scratch). Bloodly lovely bit of kit in the end, never equalled before or since—and I say that as its most rabidly demanding and intolerant user.:) Still kicking myself for blowing the one chance to get it bundled in Mac OS X itself; Apple Automation would be in a very different place today if it had.
I used Hammerspoon as an AutoHotKey replacement for automating repetitive actions in games like Terraria.
I had macros for mining up, down, left, right, and in all diagonals (eventually expanded to also placing dirt below me so I don't fall into a chasm and die), and eventually integrated mining with placing rails for underground transport!
My reasoning was that I enjoyed the action parts but not the walking parts, so I made a train tunnel, but that was even more boring than walking, so I automated it. Eventually I was having more fun automating the game than playing it.
Oh, side note, getting infinite money and life in CheatEngine (also has Mac version now) taught me an important life lesson. Using my cheat-superpowers I defeated Wall of Flesh (who had been obstructing my progress for weeks), and suddenly felt a deep sense of dread. I hadn't really achieved anything, I had cheated! Suddenly I realized I had the exact same attitude towards the rest of my life, always trying to find an easy way out, a way to win without playing the game, and that this was a source of great dissatisfaction.
I had macros for mining up, down, left, right, and in all diagonals (eventually expanded to also placing dirt below me so I don't fall into a chasm and die), and eventually integrated mining with placing rails for underground transport!
My reasoning was that I enjoyed the action parts but not the walking parts, so I made a train tunnel, but that was even more boring than walking, so I automated it. Eventually I was having more fun automating the game than playing it.
Oh, side note, getting infinite money and life in CheatEngine (also has Mac version now) taught me an important life lesson. Using my cheat-superpowers I defeated Wall of Flesh (who had been obstructing my progress for weeks), and suddenly felt a deep sense of dread. I hadn't really achieved anything, I had cheated! Suddenly I realized I had the exact same attitude towards the rest of my life, always trying to find an easy way out, a way to win without playing the game, and that this was a source of great dissatisfaction.
Then you definitely should not learn about Minetest because it has open Lua API and this is how I play it
My favorite Hammerspoon use is binding applications to hotkeys, e.g. Ctrl-3 for editor, Ctrl-4 for terminal, Ctrl-5 for browser, etc. It is so much faster going directly to an app than cycling through the apps in the alt-tab switcher.
Additionally, I use it to bind caps lock to escape, unless it’s pressed with another key, in which case it’s curl. So it’s great to not need Karabiner anymore.
Additionally, I use it to bind caps lock to escape, unless it’s pressed with another key, in which case it’s curl. So it’s great to not need Karabiner anymore.
> My favorite Hammerspoon use is binding applications to hotkeys
In linux and windows you can just use the superkey+1, 2, etc. I'm surprised macos doesn't have the equivalent to this built in.
In linux and windows you can just use the superkey+1, 2, etc. I'm surprised macos doesn't have the equivalent to this built in.
I moved at work from Ubuntu to Mac six months ago. I had AutoKey script for getting my most used password with keepassxc-cli and pasted it as text, which I had bound to Ctrl+F12. I tried to find an alternative to that on Mac and Hammerspoon was the most frequent search result. I couldn't find an easy enough example for me, though, so I went with Alfred + alfred-keepassxc workflow. It's completely different way to get passwords, how ever I prefer that now.
One funny thing while searching for information was that almost every Hammerspoon discussion had the mandatory "why not AppleScript?!" comment.
One funny thing while searching for information was that almost every Hammerspoon discussion had the mandatory "why not AppleScript?!" comment.
"why not AppleScript?!"
Rhetorical, shurely!?
Rhetorical, shurely!?
Another big discussion here 3 years ago:
https://news.ycombinator.com/item?id=12097303
(Understand it's not a dupe; sharing for info purposes).
https://news.ycombinator.com/item?id=12097303
(Understand it's not a dupe; sharing for info purposes).
I thought I recognized Hammerspoon! thanks
For me one important addition to Hammerspoon is Karabiner-Elements. I've binded my right Command and Option in a way so all my Hammerspoon shortcuts are just 2 keys. Like Right Command+T to open terminal.
If you want to go deeper into Karabiner-Elements, perhaps check out goku [0] — it allows you to write Karabiner configuration in a much nicer configuration language.
[0] https://github.com/yqrashawn/GokuRakuJoudo
[0] https://github.com/yqrashawn/GokuRakuJoudo
Please keep posting your little use cases!
I wrote a simple window manager that just lets me pick a set of windows across applications and bring them all to the front and cycle through them.
https://github.com/macrael/panes
It probably could be faster but it's so nice to be able to keep my terminal and my editor frontmost while I'm running tests with `entr`.
I wrote a simple window manager that just lets me pick a set of windows across applications and bring them all to the front and cycle through them.
https://github.com/macrael/panes
It probably could be faster but it's so nice to be able to keep my terminal and my editor frontmost while I'm running tests with `entr`.
I recently picked up this tool and picked up someone's config that does some modal keybindings similar to spacemacs [1]. It actually inspired me to hack around with their config and then write a spacemacs layer for fennel-mode which someone had written a decent version of already [2]. I'm a bit of an emacs and fennel noob, but it seemed like a fun little problem to solve. I'm especially interested in getting autocomplete working better. I've been trying to base things off of other lisps' layers, but all ears for any tips on how to approach it. I'll edit in my github later as I have everything local at the moment.
[1] https://github.com/agzam/spacehammer [2] https://gitlab.com/technomancy/fennel-mode
[1] https://github.com/agzam/spacehammer [2] https://gitlab.com/technomancy/fennel-mode
Hi, I'm the author of Spacehammer. You may want to check development branch of the project. There are some major improvements. Sadly I've been swamped with work lately and having trouble finding more time to work on it.
One of the things I'm banging my head around is adding a REPL that can work with Hammerspoon's IPC.
Once I figure that out, I'm planning to experiment on a bunch of new things and improve existing features.
My idea is to extend fennel-mode with a fennel-hs-mode that will take preprocess code by removing newlines[1] and wrapping in something like
I haven't done much yet; this is the first time I've tried to write a real Emacs mode. It would be much nicer to have a real Fennel REPL integrated in Hammerspoon, but the above would be enough for things like eval-last-sexp and org-babel-eval.
[1] Sadly, the hs cli does not handle multi-line strings.
fennel.eval([=[ (code) ]=])
I haven't done much yet; this is the first time I've tried to write a real Emacs mode. It would be much nicer to have a real Fennel REPL integrated in Hammerspoon, but the above would be enough for things like eval-last-sexp and org-babel-eval.
[1] Sadly, the hs cli does not handle multi-line strings.
Oh very nice. I will check that out more later. Definitely love the concept and would be interested in hearing if you have any future plans. I thought it could be cool to define major and minor modes like emacs that you could also "autoload" based on application names or types or even use what monitors are plugged in/wifi/times of day to switch. I suppose you have major modes already with what application is focused.
A Spacehammer REPL would be huge for prototyping/developing new features in Fennel. My github is mitchellw. Would love to help out :)
A Spacehammer REPL would be huge for prototyping/developing new features in Fennel. My github is mitchellw. Would love to help out :)
Take a look at lsp-mode for auto-completion, syntax checking, etc. I think it already works well for Lua. Should be possible to do it for fennel too.
Yeah I think it should be possible to at least autocomplete parts that can be identified as the "lua bits" of Fennel. Just gotta dig in a bit more.
Is your fennel-mode spacemacs layer published on github or elsewhere? I couldn't find it in the spacemacs develop branch.
Will publish it on my Github tonight (Japan time), mitchellw, then work on putting it in spacemacs develop branch when I can. It's crazy simple right now (just loads fennel-mode defines a few spacemacs-style keybindings for things available in that mode).
https://github.com/mitchellw/fennel-layer
Once I get a few quirks ironed out, I'll submit a PR to spacemacs to include it in the dev branch
Once I get a few quirks ironed out, I'll submit a PR to spacemacs to include it in the dev branch
This is really nice. I repeatedly wish Apple hadn’t neutered AppleScript and the scripting bridges to the point they are unusable for doing window management and suchlike.
Love love love Hammerspoon; I use it every day. People point me to all their little utility apps to keep their screen on or perform window snapping and I just write a little script and bind it to my hyper key :)
What do you use it for?
I use hs.hotkey.modal to make Alt-Space pop up a modal window that tells me what I can do. Various keys open specific apps, e.g. Return opens Finder and Space opens iTerm. Other keys move and resize the currently window to specific areas. For example, I have a specific size and position for browser windows, another one for Finder windows, a third one for instant messaging windows, and a fourth one for terminal windows.
Very very rarely do I have to manually move windows around -- I find that almost all of my needs are covered with a set of specific window positions and sizes.
I also have a window selector that displays all windows and their names and allows me to use substrings to filter the list. But I find I never use it.
I used to use Hammerspoon to implement a "vi navigation" mode, toggled by tapping the Cmd key. In vi navigation mode, hjkl move the cursor, x deletes a character, and so on. But I discovered that Karabiner Elements can do something similar, and now I'm using that instead.
I used to use Hammerspoon for a "vi
Very very rarely do I have to manually move windows around -- I find that almost all of my needs are covered with a set of specific window positions and sizes.
I also have a window selector that displays all windows and their names and allows me to use substrings to filter the list. But I find I never use it.
I used to use Hammerspoon to implement a "vi navigation" mode, toggled by tapping the Cmd key. In vi navigation mode, hjkl move the cursor, x deletes a character, and so on. But I discovered that Karabiner Elements can do something similar, and now I'm using that instead.
I used to use Hammerspoon for a "vi
Currently, a number of things: for example, I use it to switch between apps, resize windows, change my screen resolution, and give me access to system information that I paste often. If you’re really curious I have a copy if my configuration here, though it’s a little bit out of date because I haven’t cleaned up some of my new additions yet: https://github.com/saagarjha/dotfiles/tree/master/.hammerspo...
I would probably have to stop using a mac without hammerspoon at this point.
For me it is indispensable as a hotkey launcher, keyboard, window mover/resizer, clipboard history manager, stay-awake, GIPHY API lookup, pomodoro timer, and a snippet manager.
My most used combo is ctrl (remapped capslock) - ' as a launcher, then C for Chrome, J for IntelliJ, V for MacVim, ... keeps me off cmd-tab which keeps me off seeing notification number in mail and slack.
Hammerspoon is my #1 tool for modding OSX to make it more usable.
For me it is indispensable as a hotkey launcher, keyboard, window mover/resizer, clipboard history manager, stay-awake, GIPHY API lookup, pomodoro timer, and a snippet manager.
My most used combo is ctrl (remapped capslock) - ' as a launcher, then C for Chrome, J for IntelliJ, V for MacVim, ... keeps me off cmd-tab which keeps me off seeing notification number in mail and slack.
Hammerspoon is my #1 tool for modding OSX to make it more usable.
Hammerspoon is awesome, can't even imagine how difficult it would be without it.
I've built Spacemacs inspired config so I can do everything and still keep my fingers in the home row
https://github.com/agzam/spacehammer
- Tossing windows around?
- Controlling music?
- Jumping between apps?
- Adding more convenient shortcuts for your favorite apps?
- Editing any text anywhere with your favorite editor?
Why not modality then?
- Tossing windows around?
- Controlling music?
- Jumping between apps?
- Adding more convenient shortcuts for your favorite apps?
- Editing any text anywhere with your favorite editor?
Why not modality then?
Others have mentioned the window positioning features, but the other thing I use Hammerspoon for is a dark mode toggle in my menu bar.
Not something most people are switching all the time, but if you're writing CSS for a
Not something most people are switching all the time, but if you're writing CSS for a
prefers-color-scheme: dark
You can toggle between the two quickly from Safari’s Web Inspector.
Just for the web view or for the whole system? I think I’d rather look at and design dark mode content within the context of the whole screen in dark mode, but I could see that being handy for making quick little fixes.
Just the current website. It’s faster than waiting for the entire computer to switch…
I used it to get my IDE window into a pixel perfect size for recording screencasts. Pretty nifty tool.
I love the idea of Hammerspoon but I have yet to figure out a single concrete use-case for me that I actually care about. It feels like a lot of what I see people talking about is window management but I don't want window management (I actually like overlapping windows). Jumping between apps doesn't really matter either, I usually need my mouse with a lot of apps so it's not a big deal to click them in the dock if cmd-tab isn't good. And I already use an Alfred workflow for hotkeys to control iTunes.
I actually had Hammerspoon installed for multiple years on my home computer and the only thing I ever wrote with it was a hotkey to reload my Hammerspoon config.
I actually had Hammerspoon installed for multiple years on my home computer and the only thing I ever wrote with it was a hotkey to reload my Hammerspoon config.
While I’ve found hammerspoon works great for window management, I’ve recently explored trying to create semi advanced automation workflows with it and I agree that it’s not really fleshed out for this type of work (although it seems doable)
[deleted]
Seems like it's Lua with hooks into the OSX api.
Lots of useful examples https://www.hammerspoon.org/go/#table-of-contents
Lots of useful examples https://www.hammerspoon.org/go/#table-of-contents
There's a great book by LeanPub on Hammerspoon.
I'm the author of that book! Glad you found it useful :)
I absolutely love Hammerspoon, it's my favorite Mac tool. My config is available here, in case anyone wants some ideas of what it can do: https://github.com/zzamboni/dot-hammerspoon/blob/master/init...
I've been using the totally outdated Slate [0] for years now and it still works through multiple MacOS upgrades. One day I'll port to Hammerspoon I keep telling myself. It probably won't happen until Slate stops working.
[0] https://github.com/jigish/slate
[0] https://github.com/jigish/slate
Hammerspoon is invaluable for providing window rearranging functions lost when Spectacle stopped working on my Mac. Unfortunately I haven't been able to understand the structure well enough to create my own scripts.
happy user. I LOVE Lua, and would happily use anything in lua.
I mostly use Hammerspoon for moving windows to a fixed position with a keypress, e.g. left half, right third, move to other monitor. Not fully tiling, but close.
I would love to have it to automate
sudo killall -STOP -c usbd
Don't use Hammerspoon, but I've managed to create `sudo killall` keybindings with skhd by wrapping AppleScript.
cmd + shift - 9 : /usr/bin/osascript -e 'do shell script "killall coreaudiod 2>&1" with administrator privileges'
Just curious, why do you need to do this?
Possibly for the bug/feature that causes an iPhone connected by USB to connect and disconnect repeatedly on a ~2sec cycle, The bug leads to endless modals appearing on the iPhone, and sometimes iTunes opening with each reconnection.
Does anyone know how Hammerspoon compares to keyboard maestro?
Hammerspoon is free, but you have to write your automation scripts in Lua. If your comfortable with Lua this might be totally fine and give you a lot of flexibility.
Keyboard Maestro on the other side is commercial software with a nice UI editor were you can compose automation scripts by simply dragging and dropping actions. Personally I use Keyboard Maestro and find it absolutely worth its money. Even without any programming experience you can create powerfull scripts within minutes. I use it as clipboard manager, snippet manager, text expansion and much more.
Keyboard Maestro on the other side is commercial software with a nice UI editor were you can compose automation scripts by simply dragging and dropping actions. Personally I use Keyboard Maestro and find it absolutely worth its money. Even without any programming experience you can create powerfull scripts within minutes. I use it as clipboard manager, snippet manager, text expansion and much more.
Also see WinTask for windows automation with VBA
hammerspoon would be great if they have a plugin store where non-power user can just browse and install plugin of their choice.
[deleted]
Anybody know if there is a python equivalent?
what do you guys think about RPA market ?
This is siiiiick
* As a replacement for the classic caffeine app. [1]
* To provide shortcuts for window managements. [2]
* To shutdown bluetooth on sleep. Otherwise, devices I have setup to pair with both my mac and phone will tend to pair with the mac, even though it's asleep. [3]
1: https://gist.github.com/heptal/50998f66de5aba955c00
2: https://github.com/miromannino/miro-windows-manager
3: https://gist.github.com/ysimonson/fea48ee8a68ed2cbac12473e87...