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.
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:
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!)
Have every command first go through an extra navigation layer before then drilling down (as @gerbenzaagsma suggests.
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
How dare you not do lots of unpaid work to satisfy our whims?
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!
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!
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
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?
thanks
nara
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.
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.