4.7 KiB
Chronometrist-Assist
This is highly experimental and not in a usable stage, and thus lives in the assist
branch.
TODO -
- Investigate this as a solution
basic outline
- user defines
chronometrist-patterns-list
in the form'(("PROJECT" :PATH ... :MODE ... :REASON ... :HIDE ...) *)
and enables suggestions/auto clocking chronometrist
addschronometrist-assist
tofirst-change-hook
- User edits a file, triggering
first-change-hook
- If
chronometrist-assist
is 'suggest or 'auto, for each entry in the list,chronometrist-assist
checks if the file path matches:PATH
or if the current buffer major-mode matches:MODE
. For the first entry that does, it takes the configured action (suggestion or clock-in). If there is no matching entry, it does nothing.
Problems
How will this work when working with multiple windows? Multiple file types?
- paths seem to be a better choice than modes now, eh...
first-change-hook
doesn't seem to understand when a user is editing a file
Lack of the assist feature taught you some self-control - you didn't go about switching between projects so frequently, because there was some overhead of clocking in/out involved.
- The reduced jumping between tasks also means your activity 'history' is a lot less fragmented and easier for a human to read.
If you decline the prompt, you tend to get asked again very soon. Maybe remember the rule that matched and don't ask for it again for X minutes?
Asked for non-user-edited files
- if you use :PATH, you
- maybe minor mode?
("Programming" :path "\.emacs\.d" :mode ("emacs-lisp" "markdown" "org"))
matches all sorts of program-generated buffers and screws up your init and quit /o\
Why on earth does the Chronometrist buffer itself get matched? It's not even associated with any file!
Keywords
:REASON
- t - default, always ask
- string - use as initial contents when asking
- function - use result as contents
- nil - never ask, always leave blank
:HIDE
- if t, don't show the project in the Chronometrist buffer (but do show it in Report and Statistics). Effectively a way of 'deleting' the project without removing its entries from the timelog file.
Expressing and/or
Problem - sometimes you want a path AND a mode to match, and sometimes you want to OR them.
- :PATH and :MATCH could be AND'd, actually. To do an OR, a project could have more than one entries -
'(("Project 2501" :path ("path 1" "path 2") :mode "mode 1" :reason "reason 1")
("Project 2051" :path "path 2" :mode "mode 2" :reason "reason 2"))
In this, the same project will get different reasons depending on whether (AND "path 1" "path 2" "mode 1") conditions apply OR (AND "path 2" "mode 2").
- That's not how
:HIDE
should work, though- maybe any occurrence of it can mean "hide this project"
- or maybe only an occurrence in the first entry for the project
- or maybe create a separate list for projects to be hidden
An alternative approach - support :path (or "path 1" "path 2")
(but that doesn't make no sense for :mode
...)
- maybe multiple arguments to :path should always be AND, and multiple arguments to :mode always OR?
My usecase - '(("Programming" :path "programming"))
I want to clock-in for all Markdown, Org, and Elisp files in this directory, but not for HTML.
Waaaaiiiitasec. These are regexps. They have AND and OR built in!! 🤦♀️
Urgh, I now realize I also need to filter assistance to only buffers associated with files...what if, instead of :path
and :mode
, we just ask the user for a function which is passed the buffer object?
suggest/auto clock out
- never
- on save
- User can just add to
after-save-hook
:\
- User can just add to
- idle timer
- Not an ideal (ha) idea - what if the user is still working in Emacs, but on another project? Idle timer won't trigger, they'll stay clocked in to the old one...bad.
- A timer, then? Remember the condition entry that triggered the clock-in, see if any files/buffers that match it have been modified since X seconds - if not, take action.
Projects as trees or tags
I seem to be using clock-out reasons as a way to describe projects more specifically...which seems like a clumsy hack stemming from the lack of task-trees/tags
I would like to use an s-expression backend for trees
- Not really necessary - you can keep using the timeclock-file format, and just store the tree relationships in a separate file.
- Tags could be shoehorned into the timeclock-file format too, we'd just have to change the way we read it. Each 'project name' would become quoted CSV tags.
An example -
'(("OSM" "Surveying" "JOSM")
("Music" "Guitar" "Keyboard" "Singing" "Sequencing" "Composing"))