Support arbitrary extensions

[smichel17]

Rather than just having support for hidden and due extensions and adding additional extensions as they are requested, we could add an extensions data member that is an array/object using key:value pairs, where the key is the extension and the value is an array of values for that extension

So, example task dep:1 dep:2 h:1 would parse to

{ text: "example task"
  extensions: { dep: [ '1', '2' ]
                h: [ '1' ]
              }
}

It allows anyone using the jsTodoTxt to implement their own custom extensions without building in behavior that breaks the todo.txt standard (or having to do other people's work for them, if they want to use this to parse tasks and support their own custom extension).

[jmhobbs]

That seems reasonable, I'm looking for the counter case here though.

Is <key>:<value> the only way we would see it being extended? Perhaps extensions might contain more logic than that though, is it reasonable to pull that logic up a level?

I wonder if we should implement an extension system that allows for deeper parsing/composition hooks, of which a key:value extension could be one.

Thoughts @bartlibert?

[smichel17]

What kind of deeper parsing are you thinking of?

<key>:<value> is the format for add-ons in the todo.txt spec. IMO, this library should stick to a barebones implementation of that spec, and leave any deeper parsing (eg, implementing an add-on) to another library (which might also be authored by you).

[smichel17]

If I were going to implement from scratch, I think I would use this data structure, which I will describe in examples instead of words because js arrays are "wonderful".

var task = new TodoTxtItem( "(A) 2016-09-27 Log issue on @github for +jsTodoTxt @computer due:2016-09-28" h:1);

console.log(task[0].text);
// "(A)"
console.log(task[1].type);
// "date"
console.log(task[5].value);
// "github"
console.log(task[10].type); // No thought went into choosing a symbol
// "*h"

console.log(task.filter());
// "(A) 2016-09-27 Log issue on @github for +jsTodoTxt @computer due:2016-09-28"
console.log(task.filter( ["priority", "*due"] );
// "2016-09-27 Log issue on @github for +jsTodoTxt @computer h:1"
console.log(task.parts( ["priority", "text", "context", "project", "*h"] );
// "2016-09-27 Log issue on @github for +jsTodoTxt @computer h:1"

console.log(task.context[0]); // Internally, just store [5] and this will be a function call
// "github"
console.log(task.contexts; // Internally, [5,8]
// ["github", "computer"]
console.log(task["*due"])); // Internally, [9]
// ["2016-09-28"]
console.log(task["*t"]); // Check if the "t" extension is in use
// undefined

[jmhobbs]

What kind of deeper parsing are you thinking of?

No clue! Just wondering if it was a thing.

: is the format for add-ons in the todo.txt spec. I

In that case, yes, we should support it explicitly.

[jmhobbs]

I think we should move the extension parsing into the main body, but I would still like to include the possibility of explicit extensions including their own logic on top, i.e. the DueExtension parsing and validating the date.

[smichel17]

I agree that it would be nice to have support for extensions like hidden, due, threshold... but why not provide those in another library that wraps this one? eg, jsTodoTxtExt

Or we could provide those as utility methods that aren't baked into the object, like render.

Or include it in this library, as a separate object ExtItem (or something like that).