Update plans & readme

README.md

@@ -18,7 +18,7 @@ For that, a task management system needs to enable these three actions:
 
 # Design
 
-The most important rule: Everything is a task. There is nothing else.  
+The most important rule: Everything is a task. There is nothing else.
 
 Projects, Areas, Epics - they can all be mapped onto tasks, and doing so will allow you to leverage the same toolset on everything.
 A project or epic is a completable task with subtasks - it can itself be a subtask.  
@@ -30,68 +30,34 @@ More fundamentals:
 - UNIX philosophy: use plain text is possible, separate into independent modules
 - Complete control: Inbuilt reports and attributes should use available configuration, so that the user can change fundamental parts of the system
 
-## Task attributes
+## Task types
+There are essentially 4 types of things we do:
+- tasks: things to be done once e.g. hand in an assignment, fix a bug
+- activities: can't be completed e.g. browse the internet, gaming, spend time with family
+- habits: repeat in a set interval, e.g. go for a run daily, pay rent - sometimes skippable
+- chores: recur in regular intervals without a strict due date, e.g. do laundry, cut nails - can be postponed but not skipped
 
-A task has attributes, and each attribute is of one of the following types: 
+Even though they won't be clearly distinguished by a single property, they will be mapped through some default properties:
-- string, timestamp, number, date
+- Inspired by [tasklite](https://tasklite.org/concepts.html), habits have a `repeat` property while chores have a `recur` property - both can be frozen.
-- a list of each of these(or only string?) is possible as well
+- Tasks and activities may be distinguished by a `size` property, where activities have a special size value of `-`, marking them incompletable. Alternatively, activities may be prefixed with a star as it is done in Todoist
-- it should be possible to restrict a property to a set of values (enum)
 
-Special attributes:
+These basic types also incorporate other types:
-- id: string
+- an area is simply an activity with subtasks
-- parent: string
+- a project is a task with subtasks
-- entered, modified: timestamp
-- urgency: number-computed
-- status: enum-string-computed
-- virtual tags?
-- completable: boolean
 
-Standard attributes:
+Since "task" is one of these types, entities of any of these types can be called "items" within the implementation to avoid confusion.
-- tags: list-string
-- annotations: list-string
-- wait,scheduled,due,until,recur: timestamp
-- relativeRecur: boolean
-- start,stop: timestamp
-
-Custom attributes
-- priority, size: enum-string
-- url: string
 
 ## User Stories
-
 - areas
 - housework projects
 - GTD
 - Agile
 
-## Reports I need
+### Reports I need
-
 - Review active projects
 - 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
-
-`<id> add <mods>` - add a new task with <id> as parent
-
-## Selected Task
-
-If there is no selected task, the selected task is assumed to be an empty invisible root task
-
-`cd <id>` - select the given task (alternative names: open,select,ct("change task"))
-
-`show` - show details for the currently selected task (maybe also subtasks)
-
-`list` - list all direct subtasks
-
-`tree` - recursively list subtasks
-
-## More commands
-
-For more, see [taskwarrior] for now...
-
 # Inspirations
 
 ## Taskwarrior
@@ -100,12 +66,12 @@ I have been using [taskwarrior] for a few weeks now, but I am already starting t
 
 ### Issues
 
-- A big issue holding me back is a missing notion of subtasks. You either have to use projects, dependencies or create a complete custom hack - either a script or hook.
+- A big issue holding me back is a missing notion of subtasks. You either have to use projects, dependencies or create a complete custom hack - either a script or hook. This also makes entering tasks more verbose as I have to specify multiple tags repeatedly which could otherwise simply be inherited.
 - Recurrence is a longstanding issue, but can somewhat be solved by plugins: https://github.com/tbabej/task.shift-recurrence and https://github.com/JensErat/task-relative-recur
 - UDAs have a lot less options than inbuilt properties
 - CLI can be too verbose: I am missing some way to set shorthands for attributes, e.g. "p" for project, dates are rather inflexible
 - Keeping all reports aligned with custom attributes is a hassle, since you can't base reports off each other
-- ids shift around annoyingly, so you constantly have to look them up
+- ids change whenever a task is completed, so you constantly have double-check or might complete a wrong task
 
 ### What it does well
 
@@ -118,4 +84,3 @@ I have been using [taskwarrior] for a few weeks now, but I am already starting t
 [taskwarrior]: https://taskwarrior.org/  
 https://tasklite.org/related.html  
 https://www.wired.com/2016/03/best-to-do-list-app/
-

dom

@@ -0,0 +1,18 @@
+# This is a documentation by example of the DOM of Tofo
+
+attribute.all.type=string
+attribute.all.order=desc
+attribute.all.string.order=asc
+attribute.all.date.order=asc
+
+attribute.sched.type=date
+
+context.default=
+context.work=+work +pc
+context.config=+config +pc
+
+report.default=.next
+report.next=type:task
+
+item.all.target=.sched || .due
+

plans.md

@@ -2,21 +2,29 @@
 
 The implementation is split into two parts:
 
-The [plumber][plumbing], wrapping low-level storage/database access to the database and providing commands such as:
+The [plumber][plumbing], wrapping low-level storage/database access to the database in verbose commands, and the porcelain, providing a pretty interface to it.
+
+## Underlying implementation - [plumbing]
+
+Provides 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.
+To speed up development, I am considering [tasklite] under the hood for now rather than developing my own plumbing tool.
 
 Additional relevant commands:
 - runsql -> providing low-level access
 
+### Taskwarrior
+
+Since I am currently running [taskwarrior], this might also be a good foundation. It is also more tolerant about custom properties than Tasklite.
+
+It has worse performance and some shortcomings, but these can mostly be addressed by the porcelain layer. A weak point however is that access isn't as powerful as with SQL, e.g. listing all subtasks of a parent can't be done as easily.
+
 ## 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.
@@ -79,8 +87,66 @@ size.shorthand=s
 
 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 
+Especially important is the support for tree displaying -> using the parent relation, as well as incorporating datestamps of parents.
 
+### Configuration
+HOME=$XDG_CONFIG_HOME/tofo
+
+$HOME/\*rc for general configuration - multiple files allow cleaner config
+-> alternative: directory structure mimicking DOM for UNIX-style, but worse performance
+
+$HOME/hooks contains hooks:
+- on-start/on-exit
+- on-change (any task change, add or mod)
+- on-add (new task)
+- on-mod (existing task changed)
+
+$XDG_CACHE_HOME may contain the current state (context/entered task), since resetting that does no harm. Depending on the implementation, it could also hold a cache of the compiled rc.
+
+# General plans
+
+## Task attributes
+
+A task has attributes, and each attribute is of one of the following types: 
+- string, timestamp, number, date, list (of strings)
+- it should be possible to restrict a property to a set of values (enum)
+
+### Special attributes
+- uid: string-computed (ulid/uuid)
+- id: string (generated automatically, user-friendly but can be changed)
+- parent: string
+- entered, modified: timestamp
+- urgency: number-computed
+- status: enum-string-computed
+- virtual tags?
+- completable: boolean
+
+### Standard attributes
+- tags: list
+- annotations: list
+- wait,scheduled,due,until,recur: timestamp
+- relativeRecur: boolean
+- start,stop: timestamp
+
+### Custom attributes
+- priority, size: enum-string
+- url: string
+
+## Command ideas
+- `add <mods>`: add a new task under the currently selected one
+- `<id> add <mods>`: add a new task with <id> as parent
+
+### Selected Task
+If there is no selected task, the selected task is assumed to be an empty invisible root task
+- `cd <id>`: select the given task (alternative names: open,select,ct("change task"))
+- `show`: show details for the currently selected task (maybe also subtasks)
+- `list`: list all direct subtasks
+- `tree`: recursively list subtasks
+
+### More commands
+
+For more, see [taskwarrior] for now...
 
 [tasklite]: https://tasklite.org
 [plumbing]: https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain
+[taskwarrior]: https://taskwarrior.org/