This commit adds the ability for users to set an estimated duration and due date to a task, and also allows a task to be marked as completed. The new commands "show pending/completed" allows these stats to be viewed. The new command "task <task> estimate/due" allows the estimate and due date to be set, and "stop complete" can be used instead of regular "stop" to also mark a task as completed.
This commit includes changes to allow the `delete` command to remove just log entries, and not schema details (i.e. tasks and tags). Diary and todo entries associated with the task log entries will also be removed. Note that todo entries are associated based on completion time, so uncompleted todos will never be deleted unless their associated task is deleted. This commit also expands the range of dates accepted by the `PastCalendarPeriodSubtree` class in datetimeparse so that it accepts entries of the form `before <date>` and `after <date>`, where the missing start/end date is Jan 1 1970 in the first case and the current date in the second.
This commit adds a simple constraint to the `show diary` command which always limits the output to the preceding 4 weeks (more accurately, 28 days). To display diary entries over a longer period, the `summary` command can be used.
If the current task has been running for more than 8 consecutive hours, ttrack will now display a warning of this fact. The check is performed once at startup and again every time a command is entered. The warning will only be displayed once for a given task until ttrack is restarted or until the task is changed.
To cope with cases where the "shutdown" time isn't set properly (e.g. if a process is killed hard), this commit adds an additional lastseen_time which can be set regularly by a client application while it's running. On startup, if the lastseen_time is later than shutdown, the latter is replaced with the value fo the former.
…ec6d2e git-subtree-dir: cmdparser/docs/source/graphitetheme git-subtree-split: 5ec6d2e2e352d1ec589bb01214c7b23e8611865a
This issue fixes a bug where the parse tree for `DateSubtree` would accept bare days of the week (e.g. `Wednesday`) but the code to convert the text to a `datetime` would raise an exception. The interpretation of such a phrase is to assume an implicit `this week` after the weekday.
This commit includes updated docstrings for both cmdparser.py and datetimeparse.py and also Sphinx sources and makefile to generate HTML and other documentation. I've also included a custom theme "graphite" which is a light-on-dark theme that I find reduces eyestrain. As well as documentation changes, this commit also includes a new unit test as "named tokens" weren't being tested previously.
Added sections about installation and added references to the repository and issue tracker to the READMEs. Also updated URLs in the setup.py to point to the GitHub-hosted websites (currently just a mirror of the READMEs converted to HTML).
This commit moves files around into a more organised fashion suitable for use with distutils setup scripts, and also adds a few required files to allow unit test discovery and to support distutils. The repository is now split into two sections as cmdparser is potentially useful as a stand-alone library. Perhaps tracklib may be one day, but currently it's much more closely tied to ttrack itself. Note that all the READMEs are now in restructured text format, and the top-level README is simply a link to the ttrack one.
Anywhere where a time is accepted in ttrack it should be possible to use one of a set of tokens which represent the time at which various events occurred. The tokens are only available if defined, but once set they're persistent until replaced. The currently available set includes: - startup (time ttrack was last started) - shutdown (time ttrack was last quit) - taskstart (time any task was last started) - taskstop (time any task was last stopped) - diaryentry (time a diary entry was last entered) - todoadded (time a todo was last added to any task) - tododone (time any todo was last marked as done) To implement these tags a new "info" table has been added to the database schema, and I took the opportunity to also add a schema version to this table - this will be useful as and when any incompatible changes to the schema need to be made. This version should NOT be incremented for compatible changes (i.e. if a new table is silently added at startup, or a new column with a sensible default value is added). In a related change a new "info" command can be used to view the current version of ttrack, some summary statistics about the database and a list of the available time aliases and their values. This command should be updated for any other items added to the "info" database table in the future. Finally, a small change to the datetimeparse module to add "now" as an available time of day.
The DateTimeSubtree should accept a bare time of day and assume today's date for it. This commit adds this by simply making the date phrase optional when the time comes first, and adding the relevant logic to detect this to the convert() method.
All ttrack commands now use the cmdparser library to automatically generate a parser for the command based on the command syntax in the docstring. Command error reporting is quite different as a result (hopefully more helpful) and a lot of the boiler-plate error checking and command completion functions have been stripped out. The new datetimeparse library, based on classes in cmdparser, now replaces the third party parsedatetime library. This is mostly because this library made some annoying assumptions - for example, days of the week defaulted to the next instance, which is almost never what you want when adjusting start/stop times. The new library also allows a much nicer syntax for specifying periods (see next paragraph). The summary command has seen some significant syntactic differences - instead of choosing from a fixed list of period types (day, week, month), a fairly freeform date/time syntax is now permitted, which can run between arbitrary dates. The underlying library always supported this, but there wasn't a good way to express it in the command syntax. This commit also introduces considerable new functionality into cmdparser, adding a Subtree class to allow an entire parse tree to be "hidden" behind a single token in the top-level tree, including a conversion function which can squash syntax down to useful values (for example, datetimeparse uses this to convert to a datetime instance).
Amended the matching functions to return more helpful error messages about the nature of parsing failures. Also made the AnyToken and AnyTokenString classes suitable for subclassing by adding a validate() method which can be overridden. Updated unit tests appropriately.
Any item can now be optionally repeated by adding the special sequence "[...]" after it. This is can be used with Token (or any derived version), AnyToken, Sequence or Alternation. Attempting to place it after AnyTokenString or another Repeater will result in a parse error, as these cases are nonsensical. As a result of the possiblity of repetition, the "fields" dictionary is now populated with a list of values in the order they were matched from the commandline. Unit tests have been updated with basic functional tests for repetition but, as always, more cases might be useful. Also, additional tracing possibilities have been added for debugging parse errors.
Updated cmdparser so that the class and method decorators are now classes which can potentially take arguments. The only argument currently used is to provide a token factory to the method decorator. Also added a "context" argument to the matching functions. In the case of the cmd integration code, this is always set to the instance of the application-provided class derived from cmd.Cmd, so it can get real-time context information from it for completion and matching purposes. Any application which was using the underlying parsing code directly could use this parameter for its own purposes - all builtin ParseItem classes ignore it except to pass it to any children unmodified.
It's now possible to use the class and method decorator in cmdparser to implement instances derived from cmd.Cmd which use cmdparser to check syntax of commands and extract argument values. Command-line completion is automatically inserted, and method docstrings are reflowed to remove the leading whitespace of the first non-initial non-blank docstring line. Note: Currently this leading initial indent is always removed, even if it's not entirely whitespace - I should probably fix this, or change the code to calculate the minimum leading whitespace across all non-blank lines except the initial one. Currently the heuristic works for the way I indent all my docstrings, however, so the changes can wait.
Initial attempt at integrating cmdparser with the cmd module. Two new decorators have been added the cmdparser, one for use with derived cmd.Cmd classes and one for use with the methods in that class. They're designed to wrap around the do_X() methods which implement the commands and add parsing and completion to them. Early indications are that matching seems to work, at least basically, but completion isn't doing anything right now. There are not yet any unit tests for these changse - the unit test changes committed here are due to the change in interface added to allow code to detect the position in the command-line where a match failure occurred.
The cmdparser library has now had various updates for correctness and a set of unit tests has been added to exercise it. The current stage of development is that cmdparser can parse command specification strings and build a parse tree, which can be used for command matching and field extraction, as well as command-line completion. The next step is to add a base class for "Cmd" instances which scans for methods of of the form command_name() and uses them to build the actual callback functions that the "cmd" module looks for. So, the docstring of the command_name() function generates the command specification and also becomes the help of the new command. The do_name() and complete_name() functions are automatically added to the class within the constructor.
Completed "todo" item support started in previous commit. Implemented basic test coverage for the library, although some additional cases could probably be usefully added. Application should be fully updated. Also moved the diary listing functionality out of the "task" command and under the "show" command, alongside the new "todo" listing support. Added new "todo" command to add "todo" items and mark them as done. Updated the README to reflect the new changes.
The underlying library now has basic support for "todo" items on a task. These can be added at any point, and remain pending until marked as done. Items which are completed during a summary period will be merged with the diary entries (with the prefix "DONE") and items which are still pending during a period can also be queried with the pending_todos list. Items which are both started and completed either before or after a period don't appear in either of these sets. The application hasn't yet been updated aside from the "task <x> todos" command, which currently won't do anything unless the database has manually had todo entries added.
Executing the "diary" command with no arguments now enters a multi-line prompt where the user can enter a longer comment, terminating with a "." character on its own. Line breaks are respected when displaying comments, although long lines are still wrapped, consecutive blank lines are collapsed into a single blank and leading and trailing blank lines are stripped. leading whitespace on a paragraph will be preserved but probably only on the first line.
Added "task <task> diary" option to display full diary for the specified task. Also altered command so "current" can be used as an alias for the currently active task in all instances of this command. If you have a real task with the name "current", you're out of luck as the alias takes precedence. Using "current" when there is no active task results in an error.