Add plans
This commit is contained in:
parent
da2f403724
commit
47f7e9b26e
2 changed files with 88 additions and 4 deletions
|
@ -70,13 +70,11 @@ Custom attributes
|
|||
- 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)
|
||||
|
||||
|
||||
# Commands
|
||||
|
||||
`add <mods>` - add a new task under the currently selected one
|
||||
|
||||
`add <desc> <mods>` - add a new task
|
||||
|
||||
`<id> add <desc> <mods>` - add a new task with <id> as parent
|
||||
`<id> add <mods>` - add a new task with <id> as parent
|
||||
|
||||
## Selected Task
|
||||
|
||||
|
|
86
plans.md
Normal file
86
plans.md
Normal 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
|
Loading…
Add table
Reference in a new issue