This is in response to this tweet and is meant to be passed in as the <script> param to the evaluate command that’s part of the Command Line Interface.
Note that in the latest version of the CLI the script parameter can be a file path or a inline javascript. For a long script like this it’s much easier to put this script in it’s own file, then just pass in a path to that file, instead of trying to pass the entire script in on the command line:
function(tree) {
var archived = tree.evaluateNodePath('//Archive/@done'),
datesToProjects = {},
projects = [];
archived.sort(function(a, b) {
a = a.tag('done');
b = b.tag('done');
if (a < b) return -1;
if (a > b) return 1;
return 0;
});
archived.forEach(function(each) {
var date = each.tag('done');
if (date) {
var project = datesToProjects[date];
if (!project) {
project = tree.createNode(date + ':');
projects.push(project);
datesToProjects[date] = project;
}
project.appendChild(each);
}
});
var results = [];
projects.forEach(function(each) {
results.push(each.branchToText());
});
return results.join('\n');
}
Jesse - this looks very useful. For a non-coding novice, how would I implement this? I would like my Taskpaper archive arranged by date with associated completed tasks underneath:
FWIW I’m using a script (FoldingText & TaskPaper versions) which offers a menu of pre-baked or custom perspectives and reports of this kind (based on the active document, or a specified set of documents).
(The views I use tend to scan all text files in my NV folder which have file names starting with project )
Weekend water doesn’t quench mid-week thirst, but I plan to tidy the menu script up, write a few more general and pre-baked views for it, and then share it, either this weekend or next.
Not sure whether the custom view file format is really much simpler to edit and make sense of than pure javascript, but for those who are happy to tweak a JSON file, the view you describe could be defined like this, in the settings file of the script:
Hoping to get some time after the 4th to finish off some under the hood work on this (and the shell script) (to allow for a more flexible range of functions and expressions).
At the moment the underlying fn:TagSet() simply lists all tags found in the document(s), but a good idea to allow an [except] list – I’ll make a note of it.
Thanks !
PS just remembered that I have in fact added two functions to the new version which will enable whitelisting and blacklisting of tags. fn:tags_except(lstExclude) and fn:only_tags(lstInclude)
Tell me a little more about what you have in mind ?
When you say beyond the Command Line Interface view, do you mean in the FoldingText editor itself ?
(What the script essentially does is to create an additional or temporary file which is a kind of patterned summary of elements in the source file(s). The view file which it generates can be looked at in Marked, or opened in any text editor).
But perhaps I’m being slow and missing the gist of your question ?
(I’ve just restarted a bit of work on this incidentally, so a good time to tell me if you have any extensions or changes in mind).
PS perhaps more to the point – there is an applescript which runs on the active document in FoldingText, but it can only report on that file.
The advantage of Jesse’s Command Line version of FT is that you can use it in scripts which scan a number of files, and produce a summary report which combines their data.
This. While I do have a few different “action” files, I tend to work primarily from one. Every few days, I do some tidying up and pull each day’s worth of archived tasks to a text file (via NVAlt)— one file per day. If the applescript works as is on the currently active document, that’d be all I need for now.
Aside: this might be considered overkill, but I use a TextExpander snippet to mark tasks as done with both date AND time. Gives me a sense of what was completed when, and I can roughly determine when I lose focus/steam during the course of a day, and/or which tasks slow me down or simply demand more time.
