Hi,
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?
using the inter-application osascript interface (which, as here, can be used with JavaScript or AppleScript), and
building an in-app JSContext like TaskPaper’s – faster, more flexible and potentially cross-platform (iOS, iPadOS as well as macOS) but involves more implementation work (and only evaluates JavaScript code)
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.
A number of the Bike macros here are written in JavaScript – you can test them by setting the language selector at the top left of the Script Editor window to JavaScript rather than AppleScript
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.
para 1 above describes JavaScript as an alternative to Applescript used for inter application communication on MacOS. The Apple/Java script commands are interpreted as AppleEvents and processed via MacOS and this is the osascript which dates back to System7.
Whereas a JSContext may be built into an application written in Swift, Obj-C and probably other Apple Languages (as well as Microsoft Languages). With a JSContext being “a Javascript Execution Environment” ; JSContext | Apple Developer Documentation . AppleEvents are not involved meaning the target application avoids their complexity and becomes scriptable on iOS as well. I am unclear if a JSContext is able to issue AppleEvents when operating on MacOS but it seems likely that there will be a way.
How did I do ?
Also does anyone have recommendations for good books describing Javascript?
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.
Sorry, I’m not very updated on best current JavaScript books.
JavaScript books often assume that you are working with the DOM of browsers, or with the methods and asynchronous evaluation strategies of the Node environment, so the trick is to find something which deals fairly cleanly with the (quite small) JavaScript language itself.
One possibility is to work through the first 9 chapters of Eloquent JavaScript. (The remaining chapters are not relevant to osascript or to JSContext embeddings of JS interpreters).
(The first 5 chapters are really the most relevant)
There’s also a strong and sensible tradition, going back at least to Douglas Crockford’s classic JavaScript – The Good Parts, of keeping to some (possibly very small) subset of the language which simplifies things and suits your purpose.
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.