Addons can be placed in subfolders with the same name as the action,
in order to be able to e.g. clone git repos into the TODO_ACTIONS_DIR
rather than having to download addons and manage updates manually.
Closes#120
Because @contexts and +projects are metadata as much as they are text,
it can be nice to highlight them independently of the coloring of the line
that contains them. This is tough to do correctly in
a TODOTXT_FINAL_FILTER because doing it at that layer requires
re-parsing the text of the line to find the appropriate PRI_$x color to
reset to after coloring the word, or trying to reverse engineer where
the color codes inserted by todo.sh end and the user's text begins (and
vice versa).
Closes#119
Request from exatto (http://article.gmane.org/gmane.comp.diary.todotxt/4699), who doesn't want to use done.txt and report.txt.
Also consider character devices (-c; /dev/null is one) in the file existence checks so that no empty file is then created.
If not found elsewhere, look for the config file in /etc/todo/config.
`make install` installs a global config file, setting TODO_DIR=~/.todo.
todo.sh creates TODO_DIR if it doesn't exist.
The user may need the help to solve any fatal error that appears while todo.sh isn't properly set up. As the help actions do not depend on any setting that the fatal errors check, we can still invoke them.
Factor out dieWithHelp() and use that for printing the fatal errors.
Need to make match of preceding priority optional.
Also tighten patterns for priority and done marker by anchoring them to the front, as the leading task number has already been substituted away.
When the command-under-test fails with a non-zero exit code, neither the different exit code nor any output differences are printed. Also, there's a lot of duplication between test_expect_output and test_expect_code_and_output. So, let's fix both by delegating the first to the latter.
Currently, the only way to get usage help for a custom action is to use "todo.sh help" and scroll / search for the action name. (Or try to call the action without / with invalid parameters to hopefully get a one-line syntax summary.)
This extends the help command to print the usage of optionally passed custom action names.
This applies e24777fa2c to todo.cfg, too, and adds a verification to the existing test.
Note: Because todo.cfg is preprocessed by test-lib, we use the original config from the working copy, not the copy inside the test fixture.
An empty line is used to delimit test commands in test_todo_session. (This wasn't properly reflected in the usage comment, fixed that, too.) This prevents us from testing commands that include empty lines. (Currently, there is no such output in todo.sh, but custom add-ons may have this.)
Instead of forcing the test to filter out the empty lines, extend the syntax to allow empty lines in the expected output by escaping them with a single backslash. (When redirecting via <<EOF, the backslash itself must be escaped = doubled; better use <<'EOF'.)
Currently, todo.sh produces no indented output, so this hasn't affected tests so far. I found this while testing one of my custom actions with the test-lib.
By unsetting IFS, the read command won't strip off leading and trailing whitespace while parsing the test session definition.
The todo_completion had the problem that it didn't consider the todo.cfg itself for the location of TODO_ACTIONS_DIR, it just tried the default location or a globally exported config value. With the injection of custom configuration now in place, we can actually delegate the listing to todo.sh itself.
The added built-in "listaddons" command is used for that; it may also be helpful for troubleshooting or to find out about available add-ons. (But the help / shorthelp commands offer more information.)
Additionally, completion is now more precise; only executable actions and no subdirs are listed now; this is also covered by the enhanced test.
The last bonus: The custom add-on actions are now only determined when there's actually completion of commands.
This was previously not supported; todo_completion always used plain todo.sh from the PATH. Now it's possible to override the used executable (and configuration used through _todo_sh, set from a completion function wrapper.
Cp. http://tech.groups.yahoo.com/group/todotxt/message/4003
This extension of test_todo_completion additionally takes the completion function to use, so that customized completions for todo.sh aliases can be tested.
The completion may unexpectedly abort somewhere.
Additionally, reformat the failure messages (don't prepend a "*", this should be reserved to mark the individual test runs) and use "compreply" instead of "output", so that it's already clear from the diff output that the completion is being tested.
There should be a trailing newline when there are completions (to avoid diff complaining about "no trailing newline", but not when there are no completions at all.
Before adding any more features to todo_completion, I feel like I need test coverage, so this is a first stab at testing the completion results, via a new test function test_todo_completion.
Some basic tests showcase the capabilities.
Note: test-lib.sh now uses arrays, therefore all tests must use /bin/bash, not /bin/sh to avoid errors when sourcing test-lib. For consistency with todo.sh, we should have used Bash everywhere, anyway. Also note that t2000-multiline.sh needs some more quoting to avoid "Bash: ambiguous redirect" errors.
So far, the listpri action only supports a single priority. Allowing priority ranges (e.g. todo.sh listpri A-C @work) is a simple but useful enhancement.
Note: The syntax extension only clashes with the [TERM] filtering in a few corner cases, and this can be worked around (e.g. "todo.sh listpri A-Z A-Z" lists all prioritized tasks containing the text A-Z).
