3.0 KiB
3.0 KiB
Thoughts on tag-based task description
Tagging styles
- A task has a name and zero or more tags. The name describes the task at a high level, and the tags are used to refine the description. A comment can be used for additional details.
Example -
(event :name "Playing" :tags ("guitar" "solo") ...) (event :name "OSM" :tags ("survey") ...)
- A task only has tags, and no name. It is identified in the interface by the tags alone.
- A task only has tags. The first N tags (1 or 2?) form the task name.
Examples
(timeclock text format)
or (s-exp format)OSM; survey Guitar; solo repertoire
(event :tags ("guitar" "solo repertoire") ...) (event :tags ("OSM" "mobile mapping") ...)
Backend
- Timeclock-compatible CSV. May grow timeclock-project-list to large lengths, since timeclock will see every unique combination of tags as a new project.
- A new s-exp based format (see new-format.md)
- Add an s-expression containing tags and other structured data in the comment part of timeclock. Hacky, and the s-exp must be limited to one line (i.e. cannot be pretty printed), since the timeclock format is line-based.
UI
- Something to suggest tags which are commonly used with a given tag. Probably store it as a hash table or such, with tags as keys and
((tag . score) ...)
as values, sorted in descending order of scores.
UX flow
- User sees list of their tasks (names or first tags, depending on tagging system design)
- They select a task to start
- When they stop with a universal arg, ask them if they want to add any tags. If we have tag-usage history, suggest adding those tags first.
- maybe use Transient to help compose an entry instead?
- tag input must suggest earlier used tags, but must also support adding new ones.
Add new field - name of field - data -
- transient.el/hydra.el
- Just prompt for tags unconditionally. User can hit RET without entering anything to proceed without tags.
- Prefix args - C-u for tags, C-u C-u for tags and key-values. (universal-argument doesn't work nicely for my configuration, in which it is re-mapped to C-z and consequently gets buggy).
Tag UI
Should enable user to
- create new tags
- enter previously used tags quickly
- avoid misspellings
Solutions
- Use read-from-minibuffer - provides editable history, but no completion
- maybe use levenshtein.el to achieve #3
- "Add previous tags? [y]es, [n]o, [e]dit"
- completing-read-multiple - completion for multiple candidates, history, can suggest the last-used set of tags via DEF/INITIAL-INPUT
- A command which calls completing-read in an infinite loop, letting the user enter one tag at a time, and provides the user with keys to accept or cancel (quitting the loop). But completing-read doesn't have a common keymap which is inherited by ido and other completing-read replacements. (or does it?)
Default tag behavior for toggle commands (i.e. when no tagging is specified) - add no tags, or use last-used tags? (if present)