Add plans

This commit is contained in:
xerus2000 2020-08-10 03:19:53 +02:00
parent da2f403724
commit 47f7e9b26e
2 changed files with 88 additions and 4 deletions

View File

@ -70,13 +70,11 @@ Custom attributes
- Find out tasks to batch when going out - Find out tasks to batch when going out
- Find things I can do when I am (outside watching the babies e.g. cut nails | focused, wanting to do some (writing|programming) in the morning | unfocused in the afternoon e.g. check mails | taking a break from work on the computer e.g. do laundry | eating/snacking something e.g. watch a video/read a paper | listening to an audiobook e.g. digging, hang out the laundry) - Find things I can do when I am (outside watching the babies e.g. cut nails | focused, wanting to do some (writing|programming) in the morning | unfocused in the afternoon e.g. check mails | taking a break from work on the computer e.g. do laundry | eating/snacking something e.g. watch a video/read a paper | listening to an audiobook e.g. digging, hang out the laundry)
# Commands # Commands
`add <mods>` - add a new task under the currently selected one
`add <desc> <mods>` - add a new task `<id> add <mods>` - add a new task with <id> as parent
`<id> add <desc> <mods>` - add a new task with <id> as parent
## Selected Task ## Selected Task

86
plans.md Normal file
View File

@ -0,0 +1,86 @@
# Implementation
The implementation is split into two parts:
The [plumber][plumbing], wrapping low-level storage/database access to the database and providing commands such as:
- add <mods> -> add a new task
- <filter> modify <mods> -> modify task metadata
- prune -> delete tasks with status:deleted permanently
- <filter> get <prop> -> gets a property of the first task matching the filter
## Underlying implementation - [plumbing]
### Tasklite
To speed up development, I am planning to use [tasklite] under the hood for now rather than developing my own plumbing tool.
Additional relevant commands:
- runsql -> providing low-level access
## Taskporc/Tofu
My own idea for a plumber, conceptually minimal without any convenient shortcuts or configuration - just basic commands to modify and read the database.
Maybe prefix internal values (ulid and state) with underscore. Does no interpretation of parameters, only storage.
## The task manager - [porcelain][plumbing]
Name ideas: Taskforc/Tofo
Basically a parser & visualizer with a few quirks.
Unknown commands are passed on to the plumber with potential parameter modifications.
Reports & parameter configurations should support some kind of inheritance, i.e. allowing to create a new property/report that initially uses all values from its ancestor.
Automatically generates short ids for new tasks based on description - first initials, then following letters in case of collisions (e.g. "al" for "Arch Linux setup"), length may depend on whether there is a parent (root tasks get single letter if possible) unless an id is explicitly set.
### Commands
Most commands are specified in a default config file, and even most standard commands are aliases:
- _delete_=modify status:delete
- _do_/_done_=modify status:done
- _log_=add status:done
- _addx_=add status:incompletable
name tbd; this is an important concept: such tasks cannot be completed, so they can denote categories (e.g. home, work) or activities (e.g. play piano, go outside) which can turn a task manager into a time manager
This allows the user to define and redefine the commands without any programming. It provides insights into existing inner workings and makes sure that internals are accessible for power use.
#### Special commands
These commands need to be hardcoded, they can't be specified as simple aliases:
- _<id> add_=add parent:id
- _cd <id>_=selects a specific task - all further commands will be executed on this task and its children rather than all tasks
Special cases:
- `..` to select the parent
- special values prefixed with underscore e.g. `_archive`, `_backlog`, `_waiting` -> if they can be auto-generated they can also replace [taskwarrior contexts](https://taskwarrior.org/docs/context.html)!
### Parsing
The parameters for commands are pre-parsed separately, which allows custom simplified syntax. A separate config file specifies the properties with allowed values and potential shorthands, e.g.
```
scheduled.name=Scheduled
scheduled.label=Sched.
scheduled.type=date
scheduled.shorthand=sch
size.name=Size
size.values=-,s,m,l
size.shorthand=s
```
- **name** is for display in detailed info
- **label** is used as column header for reports - default: _name_
- **type** is used to potentially parse and translate the value - default: text (e.g. a date type will transform "5:00" to add the current date or even translate it to a timestamp - maybe even use the `date` command here?)
- **values** can define allowed values
- **shorthand** can specify an alternative way to specify this property on the commandline, e.g. when adding a new task
### Reports
Adds support for reports, which can also be configured in a separate config file. They can specify queries, limits, sorting and which properties to display.
Especially important is the support for tree displaying -> using the parent relation, as well as the
[tasklite]: https://tasklite.org
[plumbing]: https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain