Alfred 3 workflow for TaskPaper 3


I’ve put an Alfred 3 workflow for TaskPaper 3 up at Give it a go if you are into this kind of thing! The page includes a download link and instructions. Here is a brief summary of the commands:

See for full instructions


  • d:setdoc configure the TaskPapar document
  • d:choosedoc configure the TaskPaper document via a dialogue box
  • d:help show a brief summary of commands and settings
  • d:setremind view, change or disable the reminder search
  • do open the workflow’s TaskPaper document
  • do task create a new task
  • domail create tasks from emails selected in Apple’s Mail app.
  • dos search for and then select an item. Use modifiers cmd to toggle @done and shift to toggle @today tags
  • dop search for and then focus on a project
  • doss select and apply a search saved from the document
  • dot search for and then append a tag to any current search. Use the modifier cmd-return to instead clear the search before appending the tag.
  • dopr open resources associated with a project or to add a folder or alias resource if none exist.


  • return operate on a project
  • cmd-return operate on the Inbox
  • shift-return operate on` the Stack

The source is on github. Please let me know if you run into troubles or have suggestions.

— Rob

What's the latest on "Quick Entry" solutions for TaskPaper 3?
Bookmarklet for Safari on OS X?
How do you use TaskPaper?
Script to move cursor into editor from sidebar
TaskPaper Extensions Wiki

Thanks for trying it out. I’ve fixed the summary here to to read d:setdoc instead of the incorrect d:doc.

I’ve tried to reproduce your hanging issue by removing my copy of the workflow in Alfred 3.1.1, removing the workflow’s data directory ~/Library/Application Support/Alfred 3/Workflow Data/com.github.robwalton.taskpaper-alfred-workflow and then reinstalling from Unfortunately it works for me:

The first time I try a command it asks me to use d:setdoc to set the workflow. When I select this keyword the subtitle pops up saying ‘Searching for …’. Annoyingly nothing then happens until you start typing a search term. Try ‘*’ to see all TaskPaper documents.

As this bit of code doesn’t talk to TaskPaper, problems could be:

  1. The d:setdoc command is confusing in that you need to start typing a search term before anything obvious happens.
  2. The workflow uses Apples JavaScript for Automation (JXA). This is only available OX X v10.10 and onwards. d:setdoc uses this only once you’ve selected a file using Alfred’s file filter.

If neither of these are the answer could you give some more details. If its the first I’ll see what I can do to make it show the list before you start typing.


That works. I’d suggest d:setdoc return a list of all .taskpaper documents in the scope set in “Search Scope” for that keyword in Alfred Preferences, regardless of whether we put in a wildcard or not.

d:help does not show help unless a doc is set in d:setdoc. I’d suggest help should always be available regardless of other settings.


Thanks for the feedback. I’ve put a new version 0.9.1 up in the same place given at top of thread.

This includes your two suggestions and a few more improvements:

  • Fix help command to work when no workflow document has been configured
  • Improve d:setdoc command so that it now shows all TP docs before typing
  • Improve dop command to focus on projects properly in all cases
  • Improve search command to now show all items before user starts typing
  • Add autocomplete to script filters and fix icon references

(Couldn’t make the file filter show anything before we start typing an argument so I whipped up a script filter to get the same effect—doesn’t seem right though.)


Thank you!! Good changes.

I changed the keyword “do” to “dotv” because DO invokes Day One 2. Just mentioning because folks need to know they can change keywords if they wish. I’d rather that the “do” (or my “dotv”) not open the white-on-black HUD panel hovering over the TaskPaper document that was opened underneath. The HUD serves no purpose except to exercise our left index fingers while pressing ⎋. :wink:


This is fantastic! Thank you so much for releasing this.

My only feature request would be to search for a task and mark it as @done (along with the date). Maybe this is already possible via the dot command, but I couldn’t figure it out.


I’m finding this very useful, thank you!

The only thing that doesn’t seem to work for me is “dop [project]” always focuses on the first project (Inbox: in my case). (3.5.0 on Sierra).


Hey, this looks great, but I can’t get it to work. Whenever I run “d:setdoc”, Alfred just does a search for “d:setdoc” with my default search engine. Any ideas?


Thanks again for the feedback. I’ve put a new version 0.9.2 up in the same place given at top of thread. This includes:

  • Fix dop (project) command broken in previous release
  • Disable the remind screen feature by default
  • Add feature to toggle the @done or @today tag via the dos (search) command


I’ve disabled the nagging HUD reminder screen by default. Seemed like a good idea at the time :slight_smile:. It’s still there but you now need to enable it with d:setremind. Your left index finger may miss it though.

I hesitated over choosing the ‘do’ command names, but I think its a much better mnemonic that the alternative ‘tp’. I guess keyword collisions are a fact of life with Alfred but I can see that DayOne users may have some overlap with TaskPaper users. Had a quick look for posts or articles describing how to change a keyword (to link to) but none were obvious.


The only thing that doesn’t seem to work for me is “dop [project]” always focuses on the first project (Inbox: in my case). (3.5.0 on Sierra).

Whoops, thanks for spotting this. This is a bug I introduced in .9.1. Its gone .9.2.


My only feature request would be to search for a task and mark it as @done (along with the date).

Thats a good suggestion, and I’ve just included it in .9.2. Once you’ve selected an item with the dos (search) command you can use the cmd and shift modifiers to toggle the @done and @today flags respectively. The slippery slope of feature creep would be to add more and more ways of interacting with the TaskPaper file, but this seems to fit in naturally!

Maybe this is already possible via the dot command, but I couldn’t figure it out.

The dot command just applies a tag search. I have not actually used this one much yet, but I see that the feedback it gives is a little opaque!


Hey, this looks great, but I can’t get it to work. Whenever I run “d:setdoc”, Alfred just does a search for “d:setdoc” with my default search engine. Any ideas?

Hmm, sounds like workflow is not installed properly perhaps? Do other commands work? Without having called d:setdoc first the d:help command should pop up black HUD. All other commands should pop up a warning box saying to use d:setdoc. Also maybe try a newer version as there was the potential for confusion with this command in the initial one.


I have the exact same issue with the latest version 9.2. Could this have something to do with the location of the .taskpaper files? I have them in a Dropbox folder so they can sync with Taskmator on iOS. I added the DB folder to the search scope in Alfred’s preferences but no files show up when invoking d:setdoc.

ps: I can invoke d:help and the workflow seems installed properly.


Oh no. The first version is on github if you want to revert until I have a chance to fix this. In .9.1, against my better judgment I replaced Alfred’s standard way of selecting files with a home-brew version. This was so that it showed the full list of files before you start typing. A side effect of this is that it is not aware of Alfred’s search scope (which is not great) so your guess that this is the issue would not have helped. More so it doesn’t seem to work for everyone!

Would you try this command from Apple’s Terminal app and see if it finds your TP documents please:

mdfind “kMDItemContentType == ‘com.taskpaper.text’”

If it doesn’t find what your are looking for could you try:

mdls -name kMDItemContentTypeTree [path_to_tp_doc]

on a one of your TP docs and report back what it shows.

At this point though my inclination is to revert back to Alfred’s standard approach and improve the subtitle to avoid the confusion that it caused.


Thanks for the quick reply. To avoid confusion from my end: the workflow never worked for me (d:setdoc never showed files in all versions).

The first terminal command didn’t work. The outcome of the second one is:

MBP-van-Gerben:~ gerben$ mdls -name kMDItemContentTypeTree /Users/gerben/Dropbox/Apps/Taskmator/projecten.taskpaper
kMDItemContentTypeTree = (

Perhaps there is a way to let users set a location?


Now worries. I wanted to check that your TP document included “com.taskpaper.text” as a content type which it does. I am assuming that by ‘The first terminal command didn’t work’ you mean that it ran without error but did not return anything. In this case I need to revert to Alfred’s standard ‘File Filter’ keyword that was in 0.9, as we don’t want to go debugging this one.

Before I do so though would you mind reinstalling v.9.0 again and trying it again? You will have to disable or remove your newer version. You can confirm you are running the old one as the d:help command will either not work at all or report .9 at the top.

When calling ‘d:setdoc’ type a apace and an * and your files should pop up if they are in Aldred’s search scope. i.e.:

d:setdoc *


Actually another thing to try before reverting. Perhaps the issue you had with .9 and .9.2 is with your Mac’s search.

Can you get the search field in a Finder window to find documents of kind ‘TaskPaper Document’ at all? (I’m also concerned that when I do so I see kinds of both ‘TaskPaper Document’ and ‘TaskPaper’


Actually I found the problem. Turns out I had the Dropbox folder in my spotlight privacy settings and since Alfred relies on spotlight it didn’t look in the DB folder. My bad, sorry for the confusion…

It all works fine now, and thanks a lot for creating this workflow.


Great! Hopefully this is the issue for mediapathic too. If so, I’ll level down and maybe in the next version see if I can pop up a dialogue box to say that no files were found using OSX’s spotlight and to possibly try an alternative command that pops up an OSX file selection dialogue.