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)
<keyword>matches the RStudio project file (
- Then, depending on modifier keys:
- Default: Open the project in RStudio
- Shift ⇧: Open the enclosing folder in VS Code
- Option ⌥: Open
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:
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
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 1:
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 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 2:
You can probably ignore the Gitea-bit
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.
So, what do we learn today?
- Productivity tools are only productivity tools if you use them for productivity. Installation does not suffice.
- 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.
This is also totally not motivated by my frustration upon realizing that I used the wrong action (Launch App) instead of the “Open File” element and had to re-do/write at least 4 screenshots, 4 paragraphs of text and a ~10 second clip. This was totally planned from the start to be a ~1min clip of the whole thing, yep. Hmmhmm. No questions there. ↩︎
Can we make “LTOBOE” a thing? No? Bummer. ↩︎
If you find a cool looking workflow on packal (when it’s not currently broken), and see that the workflow hasn’t been updated in a long time, there are usually two options. A) The workflow is fairly simple and rock-solid, hence no need for updating, or B) Tough luck, it doesn’t work anymore and the creator has moved on and abandoned it. I have found examples for both cases, and it’s a little frustrating to be honest. ↩︎