These operators copy the parents of one todo item to another:

    dep add 1 parents-of 2

This will add the parents of item 2 to item 1.

Likewise, a children-of operator adds the children of item 2 to item 1.

Along the way, the _get_todos() method was refactored to simplify things
a bit.

The crash occurs when using text-based identifiers and performing an edit on
selected items (instead of the whole todo.txt file).

If you edit the text of a child item (having a p tag), then the item is deleted
using the TodoListBase.delete() instead of TodoList.delete(). But
this messes up the dependency administration, still thinking that the removed
todo item is still in the list. When you call the children of any todo item
(part of the deletion/completion step), it will return a stale Todo item, whose
number() can not be found anymore in the TodoListBase. That makes it crash.

Improve consistency of help messages.

Allow using `tag -a` multiple times

Don't crash on shlex.split error

Show some meaningful error messages instead.

Fixes #107

Add recurrence and postponing by business days

Inspired and also supported by simpletask[1].

`rec:1b` will recur after 1 business day and `rec:5b` after one full
business week. Negative values are supported.

This feature doesn't of course take holidays into account.

[1]: https://github.com/mpcjanssen/simpletask-android/blob/master/src/main/assets/index.en.md

Allow iteration of TodoList items.

Thanks @mruwek for mentioning.

This shows more consistent behavior with other prompt applications.

This commit fixes issue #106.

Not all commands always need dependencies (pri, depri, ls -x), but all
administration is still built up every time a TodoList is instantiated.
Now, as soon as something dependency related is requested from the
TodoList, the dependency graph and caches are initialized.

A decorator is used to mark methods in TodoList that require an
initialized graph.

This change impacts the calculation of the average importance (based on
the todo's ancestors). Importance doesn't have a notion of TodoList (and
I would like to keep it that way), so the calculation needs access to
the parents somehow. This was done with a parents attribute stored with
each Todo item, carefully kept up to date by the TodoList. This is
cumbersome, instead, now a Todo item gets a parents() method that
obtains the parents from the TodoList that keeps the todo item.

todo_by_dep_id was quite inefficient due to the linear search, calling
Todo.tag_value() many times to fetch the dependency ID.

Instead, maintain a dictionary that maps a parent ID to a todo item so
it can be looked up more easily.

Call Todo::is_active() only once per match, this halves the execution
time (on average).

The except path is relatively often chosen, making these functions
(still) quite slow.

(Exceptions are slow in Python and they are what they are called:
exceptions, not common cases).

Store tags in a dictionary where the key is the tag name and the value
is a list of values for that tag.

This makes tag operations much quicker (especially TodoBase::has_tag()
and TodoBase::tag_values()). They made quite a dent in execution time
with heavy todo.txt files with many tags, due to the numerous list
comprehensions that took place.

Spotted by @mruwek.

arrow is not an optional dependency
Mark optional dependencies as such.

Remove an indirect dependency from the list.

The arrow library returns more fine grained humanized dates, taking time
of the day into account. topydo only works with dates, so 'just now'
actually means 'today'.

See also this arrow issue which requests more coarse grained human
dates:

https://github.com/crsmithdev/arrow/issues/96

Python handles one exception at a time (per thread), raising a new
exception while still handling another one will result in run-time
errors. By linking the second exception to the original one, Python will
handle it correctly.

This was encountered while developing the alternative column UI, which
bailed out on completing a todo item with (invalid) child todo items.

...which is Python 3.2 based.