For other tags containing date values, try to print the relative
humanized date as well. If the tag does not contain a date in YYYY-MM-DD
value, it's normal value is printed.
ctrl-a: move cursor to the beginning
ctrl-e: move cursor to the end
ctrl-u: delete from the cursor back to the beginning
ctrl-k: delete from the cursor to the end
- completion box pops out for multiple candidates
- <Tab> and <Shift-Tab> will navigate through the list of candidates
- any other key than <Tab> and <Shift-Tab> will close the box
- completion box is glued to cursor and is trimmed to max 4 lines
- +projects, @contexts, dates and commands (with aliases) are supported
1.Rename completers
topydo.ui.prompt.TopydoCompleter is now topydo.ui.prompt.PromptCompleter
topydo.lib.Completer is now topydo.ui.CompleterBase
2. Reuse CompleterBase code in prompt completer.
3. Sort completion suggestions
4. Introduce completion of due: dates in column completer.
5. Store subcommands for completers in cache (via lru_cache).
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.
Each command can now execute action defined in its own
Command.post_archive() method after archiving action is done. Hook for
`do` and `del` is also included in this commit.
This should fix#139
Plain 'help' would crash the column UI, as would the usage of an invalid
command in an alias.
This case should be handled properly, as the CLI and Prompt mode do.
For this purpose, the generic help text was extracted, such that it can
be printed in column mode (and also in prompt mode, while I was at it).
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 will prevent from leaving TodoList and todo.txt file in
inconsistent state whenever first Command.execute() inside Transaction
succeeds and any subsequent fails for whatever reason.
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;
Lookup mechanism:
1. Check whether an editor was given with the -E flag:
topydo edit -E vim
2. Use the value of $TOPYDO_EDITOR
3. Use the value in the configuration file:
[edit]
editor = vim
4. Use the value in $EDITOR
5. Use 'vi' if the above fails.
This makes it easier to invoke an editor as vim with additional
parameters, for instance by adding the full todo.txt file to the
completion options (see the tip in issue #164). This trick was added to
the configuration file as a comment.
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?
Bram Schoenmakers