Alfred 3 workflow for TaskPaper 3

That sounds like a good idea.

The workflow works great so far! I wonder if you would consider adding an option (if this is possible) to work with multiple .taskpaper files? In other words: have the option to set multiple documents with d:setdoc and then add an extra navigation layer where a user first selects the document before drilling down into the projects within that document?

I typically have several docs open for personal and work related tasks and I imagine this could be useful. I realise this is asking a lot though so just an idea, unfortunately I’m not a programmer so it’s difficult for me to contribute to the project myself.

Hey, sorry for taking so long to see this again. I just updated to the latest version and it works now. Thanks for your work on this!

ETA: I am also looking for a good workflow for multiple tp files so consider this a +1 for looking into that as well.

I’m also unable to get this to work. I type the d:docset command and then type the filename and hit enter, but then it just executes a search in my browser. It’s unclear how to get my list of .taskpaper files to appear in Alfred. Please advise!

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

This includes, d:choosedoc a an alternative way to choose the workflow document for those who’s Spotlights are not finding their TaskPaper files. Hopefully this will help you @chrismessina ;-).

Fixes and improvements include:

- d:setdoc now warns if Spotlight finds no TaskPaper files and suggesus d:choosedoc
- Create new d:choosedoc command to choose a workflow via a dialogue box
- Cursor now correctly moves from sidebar to editor pain when selecting an item
- Fix 'do' command with no args to now open workflow doc rather than just bring TP forward
- domail command warns if Mail app is closed and no longer creates an empty entry

A few folk including @gerbenzaagsma and @mediapathic have asked about a multi-file version of the workflow. Unfortunately at present this is not something I’d use much and it is not trivial to add. Having said that if loads of people start using this workflow I might look at it (or if someone is happy to work with me).

One of the design constraints was that I wanted the workflow to always do something predictable and not depend on the state of TaskPaper (i.e. which file is open). Options to include multiple docs seem to be:

  1. Ignore this stateless principle and have the workflow operate on whatever document is open (not keen on this but it would be quick except for the corner case of when no doc is open!)
  2. Have every command first go through an extra navigation layer before then drilling down (as @gerbenzaagsma suggests.
  3. Make all commands work across multiple docs: e.g. search across multiple docs or see a list of projects from multiple docs. This would break the quick access via cmd and shift modifiers to the single Inbox and Stack.

It seems like 2 the only sensible option, but I really can’t see getting to it anytime soon. Sorry guys. --Rob

1 Like

How dare you not do lots of unpaid work to satisfy our whims? :smile:

I feel like the optimal solution would be 3, sort of. I would set a “master” doc, and that’s where the inbox and stack would go to, but then allow searching across a directory. Most of what I want for multi-doc is the ability to surface tags across multiple directories (“Which projects have something due today?”), so that would work great for my needs.

That said, @robwalton, what you’ve made here is fantastic, I’m basically using it every day. I’m working on a post about the pros and cons of a multi-file system, I’m still trying to find a balance there, so this is still very helpful. I really appreciate the work you’ve done here!

Thanks for the nice feedback!

Implementation-wise this is actually easier than 2 as its largely just code and no fiddly Alfred bits. From the usability side it sounds promising too.

I could see top level files showing up as ‘projects’ with something to make them standout (e.g. ~ prefix). The ‘dop’ (project) command at some point could get a modifier to go iteratively into a ‘project’ and show other projects inside it which would give us the drill-down feature that @gerbenzaagsma proposed.

Darn you guys and your good ideas. I might have to start doing it sometime now! Will wait for more feedback though!

@robwalton Your dedication to this is much appreciated!

This would be difficult - but perhaps option (4) might be:

d:task filename/projectname/task
d:project filename/projectname

Maybe “filename” in either of those commands could be the result returned from d:choosedoc – or perhaps if “filename.taskpaper” does not exist, then it is created. (Created somewhere. Where? Location form d:setdoc? ~/Documents/Taskpaper? Desktop?)

If “projectname” does not exist in “filename” then it’s created.

Agree with @mediapathic that option 3 would be great, along the lines @robwalton outlines in his reply. It would accomodate the broadest range of use cases.

And as for implementation, this is already a great workflow and a big thanks for creating it! Let’s see if this is something many people would like to see, not just us demanding few :wink:

With latest of everything (Sierra, Taskpaper and reinstall of this work flow) dos searches correctly BUT does not focus on the task after the search (the cursor moves to the right location but no focus)
No issue with project just for tasks
any suggestions?

Hi @Nara, sorry for long delay. Hmm, if we are talking about the same thing, unfortunately it seems to work for me okay. I just tested version 0.9.3 of the workflow from packal with 3.6.2 of TaskPaper. This was the type of thing I’ve fixed in the past though. Is it possible that a newer version of TP since Jan 3 when you posted might fix it, or more likely: which version of the workflow do you have?

Just to confirm, by ‘not focusing’ you mean the focus stays outside the editor pane, so that typing would not change the text at the (correctly placed) curser? I tried calling dos with various combinations of search and projects selected and the focus seemed okay.


I’ve put a new version 1.0 up in the same place given at top this thread.

This includes a command dorl (for read later) to grab an active webpages title, URL and highlighted text. Fixes and improvements include:

  • Added dorl (rl for read later) command to capture active webpage title, URL and highlighted text
  • Added dosn and dohn to show or hide notes respectively
  • Collapse notes in items added by do, domail or dou
  • Add ‘alt’ modifier to act on ‘Reading List’ project
1 Like

I’ve created pull request on github with Google Chrome and Mailplane task adding support.

‘dorl’ is not working for me on High Sierra and Safari 11.1, anyone else?

Hi @Riccardo, Apple have tightened the security in Safari.

To fix the ‘dorl’ command used to add a webpage to TP:

  1. Enable the ‘develop’ menu using the checkbox on the advanced panel of Safari’s preferences.
  2. In the ‘develop menu’ check ‘Allow Javascript from Apple Events’.

However, I believe this may potentially opens up your passwords to scripts running on your computer.

I’ll add a ticket to pop up a dialogue box with instructions sometime.

resurrecting this old topic to say: this is an insanely useful workflow. With the little tweak to find the right directory for Alfred 4, it seems to work fine. I don’t use Safari, so I can’t vouch for those.

I’ve started using TaskPaper again. Need to remember how to make a new workflow release to fix it for Alfred 4 but will.


I would like to get this working again for me, keep us posted! (I have not tried it recently)

EDIT: this is working fine for me!

doss is not working for me. I think I have searches not stored in the TP file, but now i can’t find that setting.

I have had Alfred for years, and way underuse it. Am trying to ramp up my Alfred ju.

doss returns searches that are saved in the current document. I may transfer them there to take advantage of Alfred “doss”