Docs: Added notes from design discussion

doc/data.txt

@@ -41,3 +41,54 @@ F: the first yes. the latter, hm. perhaps. would make sense to get the reports c
 
    --> If old data is frozen, what does that mean?  It should mean that the inclusions and exclusions are collapsed, and the net inclusions recorded and frozen. This prevents changes to the work week from modifying old information.
 
+
+P: So in this case I think I want to change it, so it’s not one day per line, but one interval per line.
+   That’s issue 1.  2 is archiving.  3 is freezing, which might be the same as archiving.
+F: I guess 1 is for easier parsing.
+P: Yes, but there’s more.  Suppose I run:
+   $ timew start monday 9am tag1
+   Then on thursday:
+   $ timew stop
+   I would rather create one interval than four:
+   2015-12-14T09:00:00-2015-12-17T16:15:00 tag1
+   The above assumes that we just run with one long interval, ignoring exclusions.  That was from your email, and it’s a good idea.
+F: One intervall is good.
+
+
+F: Regarding the exclusions...
+   I just had an idea. Which would help with 3.
+   Say we have all the definitions for exclusions.
+   These only affect the NOW and the future. Once a day (or time intervall has passed) they are recorded together with the corresponding intervall.
+   So in your example with exclusions for monday, tuesday, wednesday and thursday.
+   With that they “are” immutable for definition changes. And aren’t rewritten.
+   You have to tell timew to change them.
+   I would also help in the calculation of the reports.
+P: So if you run “timew define workday end 1745”, then that constitutes a change to the exclusions, and gets recorded in the timeline.
+   Then we essentially auto-freeze.
+   And we can reconstruct intervals and exclusions perfectly, provided we read the data, in sequence, going back to the previous exclusion change.
+   Did I get it right?
+F: Hm. I guess I meant that when you run timew stop tag1 all exclusion definitions affecting the intervall are saved together with the timestamp information of that intervall...
+P: Ah, so every line.
+F: I think so.
+   So the line would contain workday start and ends, etc.
+   Then you have all exclusion definitions affecting this particular intervall stored together with it.
+P: That is equivalent to doing this:
+   on “timew stop”, combine the intervals with the exclusions, and store only the inclusions.
+F: But then you can’t “rewrite” history in case you need. You don’t now which definitions were valid.
+P: True
+   So every line in the data contains one interval of recorded time, and all exclusions, even if they don’t change day to day.  Because they might change.
+F: Yes. And these would not be affected by redefinitions as they only apply to the future recordings.
+   Kind of like saving the “current state”.
+P: Good, I understand it.  Nice.
+   Zero loss of information.
+F: Then it is just the question when to save them. At the end, when you finish the tracking of that tag? In between as well, when doing redefinitions? Look through open intervalls, recored the current definition that is changed if it affects the intervall.
+   I would guess both.
+P: I say both
+F: Cool.
+P: If a redefine occurs in the middle of an interval, stop the first interval and record exlcusions as-is, then add a new interval to continue, but with the new settings.
+   Then a redefine just creates two adjacent intervals with different settings.
+   Great, [1] and [3] taken care of.  [2] archiving...
+   Archiving is a feature we could ignore and come to no harm.  But if we do archive, to reduce clutter, should it be automatic?  ie anything older than a month?
+   Archiving also improves performance for “timew stop”, which has less data to scan,  when closing an interval.
+F: Automatic would be good. Configurable. Then perhaps an explicite archive. Say you have terminated the work for the client, have sent the bill, got the cash. Then you could tell timew to archive the corresponding entries.
+

doc/examples.txt

@@ -65,5 +65,32 @@ associated metadata:
   $ timew define tag "tag1" end 2016-06-30
   $ timew define tag "tag1" budget 20 hours per week
   $ timew define tag "tag1" budget 400 hours total
+  $ timew define tag "tag1" overlap
 
 ---
+
+P: So the first six lines of examples show timew in use without any exclusions.  That just turns it into a stopwatch.
+F: yes.
+P: But when you add exclusions, you get to say “timew track monday tag1” and it does something less than 24 hours.
+   You also get to use fill.
+F: Right.
+
+
+F: I like the rules for days.
+   Referring to the past.
+P: Yes, I think that makes sense.
+F: Do we want to have “modifiers” for this?
+P: How so?
+F: timew track last week mon - wed tag1
+   or
+   timew track mon - wed last week tag1
+P: Yes, we do, but I would prefer this:
+   timew track last week monday - last week wednesday tag1
+F: Yes.
+P: Maybe we’ll find a better way to do this, but we need to be able to do all kinds of weird things with dates:
+   last monday, this monday, next monday, monday
+F: Would this here ever happen?
+   timew track last week tag1
+P: yes
+   That’s an auto-fill if you have exclusions.
+F: tag1 = vacation on the island

doc/grammar.txt

@@ -21,6 +21,7 @@ The CLI shall have a well-defined and unambiguous grammar.
     timew define tag <tag> end <date>
     timew define tag <tag> budget <number> <units> per <unit>
     timew define tag <tag> budget <number> <units> total
+    timew define tag <tag> overlap
 
     timew export ...
     timew import ...

doc/notes.txt

@@ -11,7 +11,7 @@ Or as sophisticated as:
   $ timew track backfill last week "Design proposal"
 
 It is not necessary to define tags, or define a set of work week exclusions,
-and without these, the software is a simple start/stop clock.
+and without these, the software is a simple start/stop clock with tags.
 
 For fully automated time tracking, as the line above exhibits, weekly and daily
 schedules must be considered. For such a tool to be useful, it must support all
@@ -254,3 +254,12 @@ P: So there are lots of time specification formats to support:
       yesterday
       etc.  Assume we support them all
 
+
+F: I think we should not only have an undo file, but also a log file.
+P: Undo like tw?
+   ie single stack?
+F: Yes. Log file: so we can see what the rules system does.
+P: Good point.
+   I like that.  I’ll add something.
+   Good for debugging also.
+   So there will now be a logging rule, to define what happens.

doc/reports.txt

@@ -40,3 +40,10 @@ P: Yeah, not sure.  Some kind of list, tabular, with subtotals.
    They would support tags for filtering.
 F: good.
 P: But yes, most people will want custom, I expect. The number of reports would grow over time I think.
+
+
+P: reports.txt
+  There is very little here, so I just want to list a few simple reports in different forms, like a calendar (like tw), and maybe in a couple of different formats.  Maybe something in HTML, maybe not.
+  I think the variations are going to be things like a title, sort by this, break by that, subtotal by this etc.
+  We could actually provide all reports as extension scripts.  Might not be a bad idea.
+

doc/rules.txt

@@ -145,3 +145,9 @@ The 'sum_week' will sum minutes in the current week for the tagset "tag1".
 
 ---
 
+P: Not sure I like the python-style.  Going with it for now.
+
+P: So rules needs a set of builtins (TBD)
+F: Builtins yes.
+   I guess we now just have to complete the grammar.
+