Some Ways I Use Keyboard Maestro

Today, thanks to Michael Tsai, I found out there’s a major new release of Keyboard Maestro. I use Keyboard Maestro all day long, and look forward to checking out the upgrade when I have time.

Here are some ways Keyboard Maestro makes my day go much more smoothly:

  • I use the palette feature to navigate to frequently used apps and documents in exactly two keystrokes.

  • I have a “Preferred Window Frame” macro that sets the active window’s size and position. My preferred frame varies from app to app, and the macro does the right thing depending on which app is active. Just one keystroke to remember. The macro invokes keyboard shortcuts I’ve configured in Divvy, but I could also have entered window coordinates directly into Keyboard Maestro.

  • I map ^P/^N to UpArrow/DownArrow so I can use those emacs keys to go up and down in lists, menus, and other places outside of text editing. The ^P/^N keys already work in many apps, but not all, and not in all places within the same app. By setting up this global mapping, I don’t have to remember where they work and where they don’t.

  • You can create text expansion macros. I have macros for inserting date and time, for a few phrases I type on a regular basis, and for emoji characters. I was happy using Keyboard Maestro for all this but recently moved my text expansion macros to aText, a very nice app at a very reasonable price. My reasons for switching were minor and arguably not worth the time when I had a perfectly good solution. I wouldn’t and perhaps shouldn’t have bothered, except I am such an obsessive yak shaver.

  • I sometimes use Keyboard Maestro instead of System Preferences to provide alternate menu shortcuts. I do this because Keyboard Maestro syncs my macro definitions on Dropbox, which means that when I make a change, all my Macs automatically get it.

  • I open Xcode’s Recent Files menu with one keystroke (I use ^R) instead of three (^1, DownArrow, RightArrow).

  • I have a scratch macro named “Pipe Text” that replaces the currently selected text by piping it through a shell script and pasting the result. The macro has an “Execute Shell Script” action that I edit to do what I have in mind, typically a grep.

  • I keep a personal log in the form of daily text files. I have a macro that opens today’s log file in BBEdit, after creating the file if necessary. I use this throughout the day whenever I think of something to add to the file.

I’m happy to share how I do any of the above.

I’m Fine With the Accents on “Fresh Off the Boat”

Yesterday I watched the first two episodes of Fresh Off the Boat, a sitcom loosely based on the childhood of Eddie Huang. It’s the first network show in 20 years starring an Asian-American family. The previous one, Margaret Cho’s All-American Girl, didn’t do too well, so anticipation and expectations were high for Fresh Off the Boat.

Last year when the first teasers came out for the show, viewers’ reactions included some concern about the accents of the parents, played by Constance Wu and Randall Park. To me, the accents did indeed sound off-key, but based on everything else I saw, I reserved judgment. I figured maybe I wasn’t familiar enough with Taiwanese accents, since I’m more used to the Hong Kong accents in my own family.

Mainly I wanted to take the attitude that I take with Apple product announcements. Whatever optimism or doubts I may have, I always reserve final judgment until I’ve had hands-on experience. I learned my lesson about that in 2007, when Apple shipped the first iPhone. I was excited about it but thought I could hold off on getting one. I figured I’d wait for other people to find the bugs and for Apple to work out any manufacturing glitches. But then a friend let me play with his iPhone, and I was immediately hooked. The hands-on experience far exceeded my expectations. Minutes later, my friend walked me to the Apple Store and I bought my own iPhone.

This week ABC “shipped” the first two episodes of Fresh Off the Boat and I finally got to go “hands-on”. And you know what? I loved the show so much I watched both episodes twice. The show is honest about race — there’s a scene in the pilot episode that I think people will be talking about for a long time — but at heart it’s a funny show with some poignant moments and some moments of dark humor (though not too dark; remember, this is ABC, not HBO). The narration by the real Eddie Huang adds great depth to the flavor of the show.

I found that the more I watched, the less I cared about the accents. They might be pitch-perfect, or they might be as questionable as James Doohan’s impression of a Scot. I’m still not sure, but I don’t care any more because I like the characters, and I like them just as they are. I doubt most of non-Asian America will care either.

Put it this way: I find Jackie Chan’s genuine accent way more distracting than I ever found Wu’s and Park’s simulated ones, and I still love Jackie Chan movies.

On Tim Cook being “the first”

Alanna Petroff, writing for CNN.com:

It’s a landmark moment for both the gay community and the business world. Tim Cook is now the first and only openly gay chief executive in the Fortune 500.

Of course, many lesbian, gay, bisexual and transgendered employees still struggle with discrimination at work. The executive suite also remains extremely closeted, but there are a few high-ranking openly gay businesspeople.

Not to detract from their accomplishments or their struggles, but none of these examples come close to Tim Cook in terms of power or visibility. It’s like pointing out the US had prominent black politicians before Obama; not to take away from any of them, but there is a clear difference. Cook is the first openly gay CEO of a Fortune 500 company, and it’s a company with a track record the other 499 would kill to have.

I remember when “Apple is so gay” was a common juvenile taunt. For all I know, it still is. Regardless, times have changed, and we should all be comfortable responding to that taunt with “You say that like it’s a bad thing.”

Double Hotkeys with Keyboard Maestro

When it comes to hotkeys, there are too few key combinations I’m comfortable with, and my memory is too weak, for me to assign a unique hotkey to each of the things I want to do quickly. Spotlight is great, but it almost always takes more than two keystrokes, often several, for me to get to what I want.

What I want is to jump to things with exactly two keystrokes. Specifically, I want one hotkey to display a menu and the second hotkey to select from that menu — basically, something as easy as old-fashioned text-based menus.

Here’s how to set up exactly that in Keyboard Maestro, which is an amazingly terrific utility.

First, create a group with the “Shows a palette for one action when:” option, and specify a hotkey as the “when”. Here’s one group I created, named “Jump to Application”, with the hotkey Control-J:

Jump to Application

Second, add some macros for things you want to do quickly. For these second-level hotkeys, I almost always use plain letters with no modifier keys, because they’re easy to type, they’re easy to remember, and they won’t conflict with any top-level hotkeys. Note that they also won’t conflict with any other macros you define in Keyboard Maestro, even if they use the same letter. Here are the ones I defined; I went a little crazy with the names of the macros, for reasons you’ll see in a moment:

Jump to Application  Macros

And that’s all there is to it — you’re done!

Here’s what I see when I hit Control-J:

Jump to Application  palette

I put the shortcut keys in the names of the macros and used tab characters to make them line up. [UPDATE 2015-08-04: Keyboard Maestro 7 displays the macro shortcuts in the palette, so I’ve removed them from my own labels.] This way, I can look at the menu (or as Keyboard Maestro calls it, the palette) to remind myself when I forget. But mostly I don’t look. I just hit Control-J,J to jump to BBEdit, and so forth.

A huge advantage of this approach is that only the first hotkey (in this case, Control-J) has to avoid conflicts with other shortcuts, or for that matter with plain text entry. Instead of trying to find twelve available and memorable key combinations, I only need to find one and pop up a menu with twelve items.

I’ve been calling this approach “double hotkeys”. If there’s another name that people use, I’d love to know. I’m also curious what other apps use double hotkeys, and what other ways there are to achieve the same thing. I loved how Accessorizer uses double hotkeys, and have since noticed it as an option in Divvy, which is a very clever app, though I haven’t made a habit of using it yet.

[UPDATE 2015-08-04: In case you’d like to try this, I’ve exported the macro group that I use for the above. You can download it here if you’d like to use it as a starting point. After downloading and unzipping the file, you can either double-click it, drag it to the Keyboard Maestro Dock icon, or use the File > Import Macros… menu option.]

Swift’s Range Operators

I was going to wait until I had more first-hand experience with Swift before blogging any opinions, but then I remembered this is the Internet. So here I am, late to the party, weighing in on Swift’s range operators, about which I have a definite opinion.

Swift’s original range operators, as defined in the first beta of Xcode 6, were:

  • x..y for a half-closed range (including x, excluding y)
  • x...y for a closed range (including both x and y)

There were lots of complaints about this choice, mostly in two categories as I recall:

  • Complaint #1: .. and ... are too easy to confuse with each other, the same way = and == are easy to confuse in C.

  • Complaint #2: .. and ... are too easy to confuse with the same operators in Ruby, which are defined with the opposite meanings.

Note that these complaints aren’t about personal taste. They’re about making it too easy to write buggy code.

Here is a complaint that absolutely nobody made, so please don’t take it too seriously, but it did occur to me as a possible annoyance:

  • Complaint #3: Some people want ... to be a system macro that automatically gets replaced with an ellipsis character.

A few people, including me, have proposed this alternative, which I am still convinced is best:

  • x..<y for half-closed
  • x..=y for closed

Here’s what I like about this option:

  • There is a parallel structure to the operators. “..” means this is a range, followed by a qualifier, either “<” or “=”, that indicates whether the last element of the range is less than or equal to y.

  • Neither operator is a substring of the other. You can’t make the mistake of typing one too few characters.

  • The meanings of the operators are clear from their appearance (addressing Complaint #1). You won’t have to pause each time to ask yourself “Which one was the closed one again?”

  • The operators don’t conflict with other languages (addressing Complaint #2). When I posted my suggestion, I didn’t think either operator had a precedent in any other language. It turns out ..< is used in Groovy, but it has the same meaning there as here.

In Xcode 6 beta 3, one of the range operators was changed. As of this writing, the operators are:

  • x..<y for half-closed
  • x...y for closed

This is fine with me, although I may change my mind if I ever start programming in Ruby. By only changing one of the two operators, the Swift designers[1] leave them half-open, if you will, to Complaint #2.

I want to mention one more proposed alternative that seems nice in theory but that I don’t think should be adopted:

  • [x..y) for half-closed
  • [x..y] for closed

This notation is already familiar to people with a little math, and easily learnable by anyone else. It’s concise. It’s unambiguous. It allows for the possibility of variations like (x..y] and (x..y).

But I think it could be open to Complaint #1. Depending on the font the programmer is using, and the resolution of their monitor, and how sleep-deprived they are, a parenthesis could maybe be mistaken for a square bracket. Or the difference might not be striking enough to register when they’re eyeballing the code, looking for why the program crashed.

Furthermore, I think mismatched brackets and parentheses could cause headaches in text editors other than Xcode. When we see an expression like that, we’re used to being able to double-click one of the delimiters to select the whole expression. I don’t know, maybe existing text editors could easily be updated to handle that, but it seems like a potential problem to me, and I do think this kind of consideration should influence language design. It’s worth looking for an option that both makes theoretical sense and plays well with the tools we use in practice.


[1] To the extent there is any such person other than Chris Lattner.