- Completed support for 'task 1 depends:2,-3' to manipulate the
dependencies.
- Now supports rc.dependency.reminder to indicate when to nag about
dependency chain violations, defaulting to on.
- Now supports rc.dependency.confirm to require confirmation before
fixing dependency chains, defaulting to on.
- New source file dependency.cpp which implements a low-level API for
determining dependency status, and assorted handlers for task state
changes.
- Adds blocking tasks to the 'next' report.
- Added more dependency unit tests, changed the wording in a couple of
them and numbered them for easy reference.
- Added dependencyGetBlocking and dependencyGetBlocked API calls, in
the ongoing effort to find a workable API for dependencies. The
goal is to make the calling code as small as possible when dealing
with dependencies.
- Corrected the algorithm for determining whether a task is blocked or
blocking to also check that the other task is pending or waiting.
For example:
task add one
task add two depends:1
task do 1
As the first task is completed, task 2 still depends on 1, but is
no longer blocked due to the completed status.
- Modified the "info" report to use the modified API.
- The "next" command had two control paths. One was via custom reports
(correct) and the other was a residual handler (obsolete), which is
now removed. This also simplifies a handleCustomReport/runCustomReport
issue.
- Preliminary export.yaml support. No unit tests yet, and no decision
on including this feature. It may be that libyaml is the right choice,
as an optional dependency.
- Added feature #415, which supports displaying just a single page of tasks,
by specifying either 'limit:page' to a command, or 'report.xxx.limit:page'
in a report specification (thanks to T. Charles Yun).
- Modified the 'next' report to only display a page, by default.
- introduced new show command to display configuration settings
- config command is used to just set config values
- modified documentation
- modified some unit tests calling 'task config' to 'task show'
- Added features #36 and #37, providing annual versions of the 'history'
and 'ghistory' command as 'history.annual' and 'ghistory.annual'.
- Uses new canonical names history.monthly, history.annual, ghistory.monthly
and ghistory.annual, with aliases providing original history and ghistory
commands.
- Updated man pages.
- Added feature #326, allowing tasks to be added in the completed state,
by using the 'log' command in place of 'add' (thanks to Cory Donnelly).
- Added log command to task.1 man page.
- Added log command to task-tutorial.5 man page.
- Added log command to help text.
- Added log command unit tests.
- changed variable name from annotation.details to annotations
- added report.X.annotations
- changed values from 2, 1, 0 to full, sparse, none
- made reportdateformat available in timesheet
- added new reportdateformat to extend the formatting of due dates
in the reports and "task info"
- added new conversion sequences a, A, b, B and Y to be used with
reportdateformat
- version now only displays the version number and copyright notice
- config displays the task configuration that version used to show
- configuration variable longversion is not longer needed
- Added a simple _version command that displays only the version
number and a newline. This makes it easier for external task support
scripts to determine which version of task is installed - easier than
parsing the version command output.
- Conditional compilation (via FEATURE_NCURSES_COLS) to either use
ncurses COLS and LINES global variables, or determine these from
the WINDOW structure.
- The next report is now a custom report. There is also a nasty
piece of logic that lets the next report exist as a custom report,
and also with it's own handleReportNext function to prep and filter
the tasks, then hand off to runCustomReport.
- Broke out the guts of handleCustomReport into runCustomReport, so
that the next report can generate it's own task list, then allow the
custom report handling to render it. This means the next report is
essentially (but not quite) a custom report.
- When a task is added, the new ID is echoed back, for convenience.
This requires a scan of the pending file, so there is a performance
hit, and the feature is controlled by the FEATURE_NEW_ID define.
