I think that the error on the "move dest src" action should be given like "SRC: No task 42" instead of "TODO: No task 42 in /path/to/src.txt", to be consistent with the addto and listfile actions. Extracted and exposed getPrefix(), again to remove a bit of duplication, and because this can be useful in custom add-ons, too.
The retrieval of a task text for $item and associated error handling so far was scattered around the individual actions. This is now consolidated in two new utility functions, which directly set $todo or $newtodo, respectively. (Inconsistent variable names like $NEWTODO have been adapted.) This ensures that all actions perform the same error checking, reduces a bit of duplication, and allows custom add-ons to benefit from these exported functions. Ah, and the error messages for the "move" action is now more in line with the other errors; unfortunately, this isn't yet covered by a test.
Note that the check whether $item is numeric must not use the +([0-9]) extglob any more, as such functions cannot be exported; a new Bash doesn't have the "shopt -s extglob" and complains with a syntax error. Fortunately, it is possible to perform the same check via standard Bash mechanisms.
This enhancement to todo_completion requires a small enhancement to the listfile action: When no SRC is specified, the list of text files in the todo.txt directory is printed. This is probably also useful on its own, and better than the original behavior of printing "TODO: File does not exist."
Note: I intentionally omitted bullet-proof error handling ($TODO_DIR non-existing or no text files contained), to avoid over-complicating this.
The double quotes used in the filter_command erroneously expand $VARIABLE, and due to missing quoting in the eval() of filter_command, multiple spaces are condensed into a single space.
Introduce a new function shellquote() to correctly quote each filter TERM.
_list() is way too large and monolithic for many (re-)use cases. As a first step, factor out the building of the filter_command and reuse that for the listproj filtering.
Enhance the listproj test with special cases that show the problems with the previous implementation directly using _list: Option -+, custom final filters, and non-ANSI colors cause it to break.
- Restore alphabetical order for "addto".
- Keep "depri" shorthand after the long form as all other.
Closes#50
Implement shorthelp listing add-on action one-line usage.
-h and an additional new "shorthelp" action list not just the usage of the built-in actions, but also from add-ons. This assumes that add-ons use the same usage indentation structure as todo.sh. (They should, anyway, for consistency of the full help message.)
Closes#12
I find it annoying that the built-in actions are printed first, and the add-on actions last, although for the user, the distinction is hardly important. Therefore, moving the "options" block first (as it is short and contains the stuff most difficult to memorize), then built-in, then add-on actions.
As environment variables are hardly used in day-to-day operations, only once for customizing the config, they are now omitted by default and only included when -vv is given.
Somehow, no default is set for TODOTXT_DISABLE_FILTER, so that it isn't exported, and therefore does not apply to the sourced actions, so you cannot disable filtering for "myaction" via todo.sh -x myaction.
The regular expression HIDE_PRIORITY_SUBSTITUTION is not anchored, so strings that look like a priority but are not at the beginning are filtered, too.
Anchoring the regexp in the step after the highlighting has been applied is problematic due to the prepended dynamic priority highlighting string, and it also cannot be done before that because highlighting needs the information. Therefore, the filtering is moved into the AWK highlighting itself.
According to the "Todo.txt Format" specs, "Rule 1: If a priority exists, it ALWAYS appears first."
Adapt AWK filtering to match priorities only directly after the task number added by the _list processing, and also matching the required trailing space.
Pull request #26 by trajano (e24777fa2c) changed `...` to $(...), but the following commit 7900ad7e1b already added another old-style one. I think the tests can also be used for some simple enforcement of coding style, so here is a first shot at it.
Closes#46
The existing check didn't do much good, and one could deprioritize any normal task without notice. Instead, check that the task to be deprioritized actually has a priority and alert via "TODO: 42 is not prioritized." if that is not the case.
The existing check (as with depri) didn't do much good. Instead, fetch the existing priority and use that information to print more specific messages:
- TODO: 42 re-prioritized from (C) to (A)
- TODO: 42 already prioritized (A)
Even though Gina's todo.txt syntax reference only mentions uppercase A-Z priorities, this is handled in two different ways in the code. I think the following guideline is useful: For a user-supplied priority (in the listpri and pri commands), use a strict check for A-Z. In general list and edit operations that need to be aware of the optional priority at the beginning of a task, use the general /^(.) / regexp. This allows addons to use different priority-like markers (e.g. "(-) no do"), have them ignored as priorities, but still maintained by replacements.
The regexp for the priority wasn't anchored to the beginning of the task. (As the filtering is done inside the _list pipeline, the task number has already been prepended.)
Also, by passing the regexp directly to _list, a case-insensitive search was performed, so despite [A-Z], lowercase characters were picked up, too. Need to make use of post_filter_command to inject a separate, case-sensitive grep into the pipeline.
Bonus: Added test for highlighting of listpri command.
This even simplified the argument handling, since there can be no invalid priority any more; all other strings are taken as TERMs. And the check for empty ${1:-} was superfluous, anyway. Apart from these simplifications, it's basically just passing $@ to _list.
Again, Bash's global pattern substitution can be used. This only depends on the "extquote" shell option, which is set by default, but we set this just to be sure.
Missing quoting inside cleaninput() condensed multiple subsequent spaces into a single space, even when the user took pains to preserve whitespace by properly quoting the task in the shell.
The 'tr' command completely removed CR and LF characters instead of replacing them with a single space.
Add test cases for the whitespace handling to the add, append, prepend and replace actions.
Despite its hard-coded use of $input, this can be useful in addons, too.
(I, for example, use this in a "todo.sh subst" addon that delegates to the "todo.sh replace" action after performing a sed-style replacement on the passed pattern and replacement.)
Improving on the previous fix and commit, no search for an unused substitution separator is actually needed; sed supports escaping of the substitution separator. Revert the $inputSep abstraction in favor of the former, hard-coded "|" character.
Commit 8e4364f5e1 removed the deletion of the "|" character from cleaninput. That was okay for the cleaninput() use in _addto(), but not in those cases that used $input for replacement via sed.
Added corresponding tests for replace, append and prepend actions similar to what was added for the add action in the above commit.
To really fix the problem (and not just remove all "|" characters from the text), a separator character must be found that is not part of $input, and this must be used in the sed expression. As cleaninput() already modifies the global $input variable, another $inputSep global variable is used to pass back this information.
In addition, backslashes must be escaped in $input, or replacements like \1 wreak havoc.
Encoding the actions that require the additional sed-escaping inside cleaninput() is cumbersome and error-prone. Instead, let the calling action tell cleaninput() that it wants this.
* Added more flags to give action developers more control over commands
that are leveraged inside their actions.
* Writing a better message for the help screen
When using the -+ or -@ option to hide project or context names in list
output, the color reset sequence was being deleted if the project/context
was at the end of the line.
For example, with the following tasks:
(B) with priority, ending in a +project
task that shouldn't be highlighted
Running 'todo.sh -+ list' would hide the "+project" from the first task,
but would also remove the color reset sequence ^[[0m at the end. The
color from the prioritized task would continue to the next lines.
This commit fixes the problem and adds a test to verify the fix.
I have placed tests for my custom todo actions in ~/.todo.actions.d/tests/; this causes a ".../.todo.actions.d/tests: is a directory" error on todo.sh help.
Added condition for regular files to the executable check in order to exclude subdirectories.
The global substitution in the AWK highlighting of prioritized and done tasks also affected the task text itself, not just the inserted color definitions.
Factored out the evaluation of the color variables and interpretation of \033 into a highlight() AWK function.
Added test cases which check that \a, \t, \n, \x.. and \0.. escape characters in the task text are listed as-is, without interpretation.
Fixed by removing the -e option that causes the echo command to interpret escape characters. Coloring of done tasks (the only step in the _list pipeline that required this interpretation) has been moved into the AWK pipeline step which is responsible for the priority coloring, and which does the escape character interpretation internally.
As a nice side effect, this shortening of the _list pipeline should also speed up the listing a wee bit.
This allows to leave off the .txt file extension in commands like "todo.sh listfile done".
Plus: Minor coding style alignment, replaced $1 argument with existing $FILE variable.
This makes done tasks more stand out (like prioritized tasks) in the task list. Default highlighting is LIGHT_GREY, which seems to be modest and go well with the assumed dark terminal background.
Reintroduced the OSX-compatible sed filter that was introduced by commit 8b7e2e6aad and superseded by the PRI_X coloring generalization.
