Configurable Syntax

[flowerornament]

After trying Atea, I for a moment entertained the possibility of submitting a feature request of the form "could you please support my syntax", but I quickly recalled that there are numerous todo list syntaxes, many of them popular, and infinitely more unique to individuals. Rather, the issue could be solved by allowing users to define their own syntax in the config file.

For instance, my todo list looks roughly like this, a combination of Markdown and Taskpaper syntax:

## Today

- task 1
- task 2 @done 

## Week

- task 1
- task 2

## Projects

Project1:
- task1
- task2

If I could, for instance, define regexp("^##\s\w") as a "comment" or "project title", I would be in business. It would be a bonus if I could define regexp(^-\s.*) as a todo item, but it's not strictly necessary. By this I mean to suggest that the parser need not be complex at all. Perhaps just introduce the notion of "categories" and "items" and let people define syntax that designates these two entities freely.

Thanks for making a great little piece of software. For now my categories show up as independent lists and it's useable enough like that. I may experiment with not using categories at all. I must say though, that prefixing the project name to each todo item is not practical in my opinion – it increases the friction in creating a task dangerously.

[pkamenarsky]

I have to say this is a pretty good idea and one that wouldn't be very complex to implement when the rules are ironed out; I just need to brainstorm what exactly needs to be configurable and how those aspects should then be composed.

I think it would be best to have "implicit" and "explicit" categories; implicit categories are those stemming from text structure - i.e. empty lines or indentation and are configured by defining functions that take a line, the previous implicit category and return a value (or nothing); when the return value is nothing, all subsequent lines have the same implicit category until a new line with a new associated implicit category. This means that a line can only have one implicit category.

For example right now, the implicit category function would just return a value only when an empty line is encountered. In your example, the function would return a new value when a line starting with (##.) or (.:) is encountered.

Explicit categories are just be a variable amount of regexps that are run on a line, for example parsing the + and @ notations in the Todo.txt format.

And finally, by providing a list of categories the sorting order can be made configurable; for example, sort by priority, then project, or sort by time, then project, then priority, or sort by location, then context, etc etc.

I would love if more people would chime in so that we can think of an easy configuration scheme that accommodates the greatest number of users.

[profer]

Maybe the easiest first step would be to split out the functions load-tasks and parse-task into a separate CLJ file that can be overridden in the configuration. Atea would then load those two functions at runtime when a different implementation is present.
I think that would be easier and more flexible than a purely regular expression based approach.

[pkamenarsky]

And since the cfg file is itself written in Clojure, this would be pretty easy.

[cj]

@msutherl great minds think alike #23 😄

[mong8se]

Another syntax to throw into the mix: workflowish

[pkamenarsky]

@mong8se Nice, inspired me to make this :)

[beakr]

Great, now I can make my colorscheme for Atea. 😄