While I have a license for Taskpaper I’m not using it at present as I keep going back to what I know which is OmniOutliner. I use OmniOutliner combined with some Applescripts to manage my tasks. The Applescripts add functions that are not available in OmniOutliner and in someways emulate some of the built in functions in Taskpaper.
Two of the functions are not available in Taskpaper and for the basis of my questions here. My Outliner not only manages tasks it also stores the resolution of those tasks. For example I recently set myself the task of ordering some new LED down lighters for the bathroom. I placed the order for the lights on-line and received an order confirmation by email. When the email was received I copied the email using an Applescript to the notes section of the task in OmniOutliner, ticked it as complete and then ran a second script that moves completed items to their own section. If in the future a lamp fails I can quickly locate the order details as they are stored within my ToDo list inside meaning that I don’t have to search my emails or folders.
I wonder if it is possible to use Taskpaper or indeed Bike in a similar way?
If you are using TaskPaper there is a command Tag > Archive @done Items. That will move any rows with a @done tag to the “Archive:” project, creating that project if needed.
In Bike you can do something similar with scripting… but also in Bike’s current public release there’s not yet a great way to mark items as @done. In Bike’s current preview release there is a good way to mark things done … the new checkbox row type.
So if you wanted this behavior in Bike I would recommend that you use the preview version with checkboxes, and then use a script to move checked off items to an “archive” part of your outline.
Moving off topic I’m curious about the two different script languages implemented in Taskpaper and Bike respectively : would it be fair to say that you don’t think Apple are going to kill Applescript in the near future?
My understanding is that starting with osascript (I think the first version of TaskPaper may originally have done that too ?) provides a quicker way of getting something in place, before deciding whether or when to go for a full JSContext.
PS I don’t think Apple are likely to actively remove the osascript interface – it’s more something that has fallen into sunset mode as they lose interest in it – its architecture (unlike that of the in-app JSContext interface) isn’t applicable to iPhones and iPads.
How did I do ?
Probably not. The JSContext is pretty isolated and not able to do any external communication … except communication that has been explicitly setup by the hosting app. So it’s possible that the hosting app would provide some functions in its JSContext to send AppleEvents, but pretty unlikely.
(The first 5 chapters are really the most relevant)
Mine, for example, happens to consist of:
Expressions only (no statements) to avoid having to think about and debug successive states. (for example I use the conditional (ternary) operator rather than if then else, and I use .map .filter .reduce and .flatMap, plus, more rarely .forEach, but no loops)
const but no let or var for the same reason
Single argument (curried) functions to ease mapping, composition, and code reuse
IIFEs to localise any value names that I define, and finally,
"use strict" to get more informative messages from the JS interpreter.
but preferences vary.
Helpful, in any case, to reduce things down to something small, workable, and solid, which you don’t have to think about too much, and which doesn’t cost you time spent debugging.