Closed nocejo closed 9 years ago
Starting from commit 918345b4912fcb5b4d45f0303e9f39ec781bda5c a branch trevcrc addresses this issue.
This looks like the way to go! fantastic!
I'm thinking about how more-complex reviews might be implemented, as an example, reviewing "required" attributes. If you consider "project" and "priority" attributes to be "required" you could set up a review for each one, naming those reviews
review.required-project... review.required-priority...
then maybe
trev required
matching both of those review definitions, might run the first review, and then the next one, in the order found in the rc, as part of the same "review".. does that make sense?
I think so, and I think it can be done. Interesting suggestion.
Incidentally, it's better to move this request to a new issue of its own, so this issue (#31) can be properly closed when basic dot file development is completed and branch trevrc merged.
Glad to hear that makes sense. So I can properly for the new issue, what would the syntax be for "calling a review"?
trev.pl review required ?
or..
The basic functionality is implemented and merged to master, then this issue is closed. Enhancements to the behavior of the rc file mechanism would give raise to other, new issues.
Issues #19 (new argument; -t 'this is ++mark and Selected text'), #22 (new argument; -f ~/.task/review/weekly.review[.txt]) and #23 (.rc option: info_view=on/off) give rise to the convenience of having a .trevrc file containing switches, default values and 'review modes'.
Specific review modes (as the active tasks, next actions,overdue tasks, marked for weekly review... proposed) can mimic the report mechanism in taskwarrior; i.e.: as the content:
defines the 'minimal' report in taskwarrior's ~/.taskrc file, some text like:
can define the 'calls' mode in some .trevrc file.