An Alfred Workflow for R Users

Over the past few years, Alfred has become one of my favorite macOS apps.
It’s definitely up there with other apps I wouldn’t want to use a Mac without: Bartender, Typinator or iStat Menus.

When I first started using it, I was pretty overwhelmed by all the things it could so, so I mostly stuck to things that felt like immediate extensions of macOS’s built-in Spotlight — which already made ⌘+Space my reflexive choice to the general problem of “finding things” or even just opening an App — Alfred was just a lot better at it.
Add better file maneuverability in the search window, custom search providers and some other bits, and there was my fully-featured Spotlight replacement.

Then I ventured into workflows by browsing packal a lot and found some neat things here and there, but I never really used all that potential to solve any problems I actually had, they were mostly just nice additions for edge cases I tended to forget I even had access to at my fingertips.

Recently I also started adding some new snippets to Alfred instead of using the aforementioned Typinator for that. I’ve been using Typinator for a lot longer than Alfred, and while I prefer the “fewest number of apps for the largest amount of functionality” approach, I haven’t bothered migrating my Typinator snippets yet. I do generally prefer Alfreds snippets functionality & UI though, so that may be in my future. My recent ventures into making hugo shortcodes have definitely given me enough reason to add more snippets though.

What I’m actually here to talk about is a small workflow I made to help with my tendency to switch RStudio projects a lot, my frequent need to refer back to older projects, and my secondary desire to open projects in VS Code as well (which is faster to open and makes it easier to work with a lot of files).

It turns out it’s really easy to get started making Alfred workflows, so here’s the gist of what mine does:

• Open the Alfred search window (⌘ + Space for me)
• Type rs <keyword> where <keyword> matches the RStudio project file (.Rproj)
• Then, depending on modifier keys:
  • Default: Open the project in RStudio
  • Shift ⇧: Open the enclosing folder in VS Code
  • Option ⌥: Open git’s origin (e.g. GitHub) in the default browser.
  • Command ⌘: Open in Finder (not configured in workflow, but ALfred offers this by default apparently)

And here’s a video of it in (semi-)action, where I only trigger the keys (see the black centered window thanks to KeyCastr) but don’t actually have it open anything to keep the video smaller (dimension-wise):

And under the hood it’s only these four elements:

Step by Step The Whole Shebang

Let’s start with a new workflow. Open the Workflow pane and add an empty workflow to fill in its details.

Once you have an empty workflow, you can add a file filter that will search and find all your .Rproj files:

Configure to new file filter with your desired metadata, like a keyword to trigger it in the Alfred search box (here I chose proj). To make it find .Rproj files, you only have to drag and drop an existing project file into the lower part of the box:

You can also give it a nice icon, like the RStudio logo which would then be displayed in the search window. For now our test workflow looks like this:

Now, to have RStudio (or VS Code) open the project, we need the appropriate action elements.
Instead of doing a screenshot-by-screenshot thing, I thought I might as well show the whole shebang in a short clip, as it’s really not that complicated as far as the required number of steps is concerned ¹:

The only tricky bit is to make sure VS Code receives the enclsosing folder of the project and not the .Rproj file itself, where this regular expression comes in handy [a-zA-Z0-9-\.]+\.Rproj$ (along with Alfreds clipboard history, another feature I never want to use a computer without).

So, start to finish, what’s that? Maybe two minutes? Neat.

The git Bit

The only bit that’s missing from my original workflow is the “open repo in browser” thing, but that’s mainly a bash thing anyway. Just add a “Run script” action, link it with your preferred modifier key and go to town.

The script I’m using looks like this — it took me a lot of stackoverflow’ing and I eventually settled on a classic less-than-optimal but optimal-enough solution ²:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

query=$1
dir=$(dirname ${query})
cd $dir

# Github
if [[ $(git config remote.origin.url | grep github) ]]; then 
  open $(git config remote.origin.url | sed "s/git@\(.*\):\(.*\).git/https:\/\/\1\/\2/")
fi

# Self-hosted Gitea
if [[ $(git config remote.origin.url | grep gitea) ]]; then 
  open $(git config remote.origin.url | sed "s/ssh:\/\/gitea@/https:\/\//" | sed "s/:54321//" | sed "s/\.git$//")
fi

The gist is to take the origin url via git config remote.origin.url and check if it’s a GitHub repository or not, and then run some good old sed find & replace to arrive at a browser-compatible url.
In the second half, I do the same thing but with the handicap that my self-hosted Gitea’s urls look a little different and contain a non-standard port (don’t @ me), so you can probably safely ignore that or tweak it to your needs.

Conclusion

So, what do we learn today?

1. Productivity tools are only productivity tools if you use them for productivity. Installation does not suffice.
2. Not every Alfred Workflow worth installing has to be a massively-featured complexity monster that sat unmaintained on packal for 5 years ³.
3. Solving your own problems is worth more than downloading/installing someone else’s solutions that work for them.

I hope at least someone finds this useful.