Topydo was only identifying a task as completed if it included a
completion date (which topydo automatically adds). This affects
compatibility with other todo.txt apps, making archiving unreliable.
Tests started failing across python versions. Tests disagree on presence
or absense of a "VALUE=..." format-specifying option on a COMPLETED and
DTS-START dates.
Modified the test reference file to match test output. This does not
introduce errors to https://icalendar.org/validator.html.
As discovered by @davesteele, `arrow.now()` is not freezed to UTC with
freezegun. We have to mock it so the humanized dates in tests are
calculated properly.
Previously, unprioritized tasks were set below all other tasks. This
change sets unprioritized tasks directly in the middle of all task
prioritizations.
Before this patch a `t edit ...` will remove todo items selected by
`...` and then do equivalent of `t add` with input from result of
editing. This works, but has the property that whenever a todo item is
edited, it is always moved till the end of todo.txt file.
This property creates noise and makes synchronization harder to implement for
some of us who uses VCS and different machines to maintain todo.txt .
-> Teach edit to preserve todo items in their places. Adjust existing
tests and add a couple more exercising cases where either new todo
items are added in the editor, or vice versa, removed in the editor.
/cc @mruwek
Starting in Python 3.7, Python emits deprecation warning for normal
strings containing what it considers invalid backslash escapes. In
Python 3.9, this situation will be a syntax error. Fix the reported
instances.
ref https://lwn.net/Articles/795546/
When you enter a todo item: "Call office at 09:00", the 09:00 would be
seen as a tag-value pair. Because of this, the timestamp would be
removed from the todo text: "Call office at ".
Discussed in issue #211.
When using numerical IDs, the ID width is padded to the log10 of the
todo length.
When using textual IDs, todo lists of 466 items or shorter pad to 3
characters, otherwise 4 characters.
The postpone subcommand would crash when postponing a todo item with an
invalid due date (e.g. due:2017-06-31).
When postponing, the due date serves as an offset. With an invalid due
date, no proper offset can be found. Instead of (silently) falling back
to today's due date, show an error instead.
Moreover, invalid creation/completion dates are also ignored.
The LimitFilter should be performed at the very last step. Instead of
complicating ExpressionCommand and ListCommand to cough up a well
ordered set of filters, order the filters when updating the view. Each
filter is assigned an order number, where filters with a higher order
are applied later.
This fixes the output when using the ls -n flag, where the truncation
appears before the hide tag filter. This results in possibly less items
to be printed than specified (or worse: nothing is printed).
Use last definition of an option instead. Section duplicates are also
supported from now.
Example:
'''
[column_keymap]
a = foo
a = bar
[column_keymap]
b = foobar
'''
is equivalent of:
'''
[column_keymap]
a = bar
b = foobar
'''
From now on:
`topydo dep ls before 1` gives the same output as `topydo dep ls 1 to`
and:
`topydo dep ls after 1` gives the same output as `topydo dep ls to 1`
This provides that each backup description will still inform user about
each command that was executed. When transaction of commands was
executed user will get printed list of commands separated by ';'.
Example:
Successfully reverted: append 1 FooBar; append 3 FooBar; append 6 FooBar;
Suppose we have the todo item:
(C) Some item key:value1 key:value2
And then I do an ls:
topydo ls -x key:value2
Before, this would yield an empty result, which is undesired. Therefore,
only apply ordinal tag filtering when a tag appears exactly once in the
todo item. This is a simple approach, and special operators >, >= etc
will not be applicable:
topydo ls -x key:>value1
will no longer work. The result could be ambiguous: filter out when none of
the tags match, or only some of them?