These are a Few of My Stateful Machines

October 27, 2017

I’m excited to be presenting at the inaugural Swift by Northwest conference today. My talk is on state machines and how easy they are to implement in Swift.

Share and enjoy.

Terminal Palettes

September 3, 2017

For some recent work, I was switching between OmniFocus and OmniPlan code often. To keep my source directories straight in my head, I tweaked the colors of the two Terminal tabs to use the apps’ branding fonts: purple text for OmniFocus; yellow text for OmniPlan. I mentioned this hack in an engineering meeting and Ken promptly dropped the nerd snipe: “Does it switch automatically?”

It didn’t then. Now it does.

With a three part solution — AppleScript, shell script, and a zsh hook — my Terminal palette now updates whenever I switch between source directories. Yours can too.

ZSH Hook

I added the following code to my .zshrc file:

if [[ "$TERM_PROGRAM" == "Apple_Terminal" ]] && [[ -z "$INSIDE_EMACS" ]]; then

    update_terminal_cwd() {
        # Identify the directory using a "file:" scheme URL, including
        # the host name to disambiguate local vs. remote paths.

        # Percent-encode the pathname.
        local URL_PATH=''
            # Use LANG=C to process text byte-by-byte.
            local i ch hexch LANG=C
            for ((i = 1; i <= ${#PWD}; ++i)); do
                if [[ "$ch" =~ [/._~A-Za-z0-9-] ]]; then
                    hexch=$(printf "%02X" "'$ch")

        local PWD_URL="file://$HOST$URL_PATH"
        #echo "$PWD_URL"        # testing
        print -Pn "\e]0;%n@%m: %~\a" # get the tab title right:
        printf '\e]7;%s\a' "$PWD_URL" # get path restore right
        ~/bin/ "$PWD_URL" # update colors

    # Register the function so it is called whenever the working
    # directory changes.
    autoload add-zsh-hook
    add-zsh-hook chpwd update_terminal_cwd

    # Tell the terminal about the initial directory.

This code first declares a local function, update_terminal_cwd(), then hooks the shell directory change command to run the function. Finally it calls the function so that a new terminal window will trigger the code as well.

Inside the function, we percent-encode the current working directory. Then we set the tab title, save the working directory so it restores on the next launch of Terminal, and finally call the script to update the color palette.

Shell Script

The script lives in the bin subdirectory of my home directory.

The script starts with a fairly standard preamble like so:


func usage() {
        echo "Usage:"
        echo "${0} (<file url>|<settings name>)"


if [[ -z ${PROFILE} ]] ; then
        exit 1

The script takes a single argument. That argument can either be a file URL, like file://localhost/Users/curt/bin

or the name of a profile, like "Man Page"

The preamble just checks for any single argument and reports the correct usage if the argument is missing.

Next, we bridge the shell argument into AppleScript so we can drive

osascript - `tty` ${PROFILE} <<SCRIPT

Invoked with - as the first argument, osascript will run a script passed in on standard input, feeding the subsequent arguments to the embedded script. Here we pass the current tty — we’ll see why shortly — and the original argument. Then we begin a here doc with the <<SCRIPT incantation. Until the end of the here doc, we’re coding in AppleScript:

on run argv
    set theTTY to item 1 of argv
    set settingsNameOrPath to item 2 of argv
    if settingsNameOrPath starts with "file://" then
        set settingsName to my settingsNameForPath(settingsNameOrPath)
        set settingsName to settingsNameOrPath
    end if

    if settingsName is missing value then return

    tell application "Terminal"
        set desiredSettings to first settings set whose name is settingsName
        if desiredSettings is missing value then return
        repeat with matchingTab in my tabForTTY(theTTY)
            set current settings of matchingTab to desiredSettings
        end repeat
    end tell
end run

The run handler extracts the tty and the original script’s argument into theTTY and settingsNameOrPath respectively. Then it detects what sort of argument was passed to the original script and converts that to a Terminal app settings name. (In grand AppleScript tradition, the UI for calls its color palettes “Profiles” but the AppleScript dictionary calls them “Settings”.) If the argument was a file URL, we call a handler settingsNameForPath — see below — to get the settings name. Otherwise we use it directly.

Then we drive the Terminal app to look up the desired settings, find the tab that is rendering the current tty, and change the settings of that tab to the desired ones.

Now we just need to define a couple of helpers.

on settingsNameForPath(thePath)
    if thePath ends with "SourceDirs" then return "Man Page"
    if thePath contains "SourceDirs/OmniFocus" then return "OmniFocus"
    if thePath contains "SourceDirs/OmniCurt" then return "OmniCurt"
    if thePath contains "SourceDirs/OmniPlan" then return "OmniPlan"
    if thePath contains "SourceDirs/" then return ""
    if thePath contains "SourceDirs" then return "Ocean"
    return missing value
end settingsNameForPath

The settingsNameForPath handler maps from the path argument to custom palette names. If you’re setting up this script for your own use, you’ll want to tweak this handler and your Terminal profiles. I added some app and project specific profiles, like OmniFocus and So far I’ve just been tweaking the handler as I add more profiles, though someday it would be nice to make this do a bit more parsing to avoid the repetitive if statements.

on tabForTTY(theTTY)
    tell application "Terminal"
        repeat with aWindow in every window
            repeat with aTab in every tab of aWindow
                set currentTTY to tty of aTab
                if currentTTY is theTTY then
                    return {aTab}
                end if
            end repeat
        end repeat
        return {}
    end tell
end tabForTTY

This last handler iterates through every Terminal tab looking for the one rendering the script’s tty. This might become too slow with a lot of tabs open, but so far it’s been fine with my usual four or five tabs at once.

Finally, we end the here doc and the script:


This was a fun bit of hackery. I hope you enjoyed it too. You can download the script in its entirety here.

Swift by Northwest Schedule Posted

August 28, 2017

Swift by Northwest has posted their preliminary schedule. The conference will be single-track with some great speakers. I love this format. Single-track conferences always feel more intimate because everyone shares the experience.

The conference is Oct. 27–28 in beautiful Seattle. If you register this week, you can still get the early bird discount.

I hope to see you there!

Swift by Northwest Plans

July 30, 2017

I’m excited to be speaking at Swift by Northwest in October in sunny Seattle. I just put the finishing touches on the abstract for my session:

These are a Few of My Stateful Machines

As app developers we have to deal with the challenges of stateful code every day. State machines are a powerful technique for managing state — but they’re underused in Mac and iOS development, in part because they can be awkward to implement in Objective-C. Swift changes that. Swift’s smart enums make implementing state machines quick, easy, and fun. In this talk we’ll look at how you can make your apps easier to write, debug, and evolve using state machines in Swift. Along the way, we’ll explore the power of enums, including associated values, methods, and properties.

Swift’s destructuring switch statements over smart enums are one of my favorite parts of the language. This session should be great fun to lead. I’ll do my best to make it fun to participate in as well.

Swift by Northwest is shaping up to be a great conference. Some of my favorite people in the Cocoa community are presenting, and Seattle is my favorite city. Early bird registration is open now. I hope you’ll be there!

Version 1.2 of Export OmniFocus View to OmniOutliner

June 25, 2017

Now available, version 1.2 of my Export View to OmniOutliner script. The script makes a new OmniOutliner document from your current view in OmniFocus.

With Version 1.2 you can now export from the Forecast perspective in OmniFocus. Due to a limitation in OmniFocus, the export from Forecast will have empty group titles in OmniOutliner. The tasks are exported correctly, however. (I hope to fix this limitation in a future release of OmniFocus.)

This version of the export script also better handles notes with embedded links.

Installing the Script

To install the script, download the latest version here. Then in OmniFocus, choose Help → Open Scripts Folder. Drag the Export View to OmniOutliner file into the scripts folder. Finally, use Customize Toolbar to add the script to the toolbar in OmniFocus.

Running the Script

Once you’ve installed the script, navigate to whatever perspective you’d like to export. You can even Focus on a particular project, or use View Options (⇧⌘V) to fine tune the display. Once the view in OmniFocus is showing just what you want, run Export View to OmniOutliner from your OmniFocus toolbar. OmniOutliner will launch and the script will create a new document containing just the information in your current OmniFocus view.

Only the titles, notes, and structure are exported from OmniFocus. The OmniOutliner document won’t contain contexts or other information, like defer and due dates, from OmniFocus. I find this is a handy way to get a summary of a project or a task list into OmniOutliner. From there, I can print to PDF to share with others without exposing the details of my own OmniFocus database.

Share and enjoy!

Drop me a note @curtclifton on Twitter if there’s something else you’d like to see automated in OmniFocus.