chronometrist/doc/assist.md

Chronometrist-Assist

This is highly experimental and not in a usable stage, and thus lives in the assist branch.

TODO -

1. Investigate this as a solution

basic outline

1. user defines chronometrist-patterns-list in the form '(("PROJECT" :PATH ... :MODE ... :REASON ... :HIDE ...) *) and enables suggestions/auto clocking
2. chronometrist adds chronometrist-assist to first-change-hook
3. User edits a file, triggering first-change-hook
4. 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 :\
• 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"))