“Ditto”-mark to take over previous entry summary #239
Replies: 1 comment 2 replies
-
|
Not sure I like the idea, because it would break the syntax of the log file just to make it seemingly more readable by a human. Yes, consider this (real) use case that would be broken : |
Beta Was this translation helpful? Give feedback.
-
|
It’s a fair point that such a ditto mark could add some non-obvious and non-straightforward “magic”, and hence might not be perfectly intuitive. (I’m, by the way, also not fully convinced yet by this idea, so it might never happen anyway.) I’d like to point out, however, that doing “naive” line-based
That being said, if you do purely text/line-based processing of your files, you have to be careful already. A ditto mark wouldn’t create a new problem, and you could just choose to not using it to avoid that situation. (In the same way as you could choose to not put tags in the overall record summary, or to restrict entry summaries to a single line.) As an aside, one general remark about the klog file format: the basic design philosophy is to find the best balance between human and computer needs. So the file format doesn’t optimise for either perspective, but it rather aims for the best compromise between both worlds. In that sense, you could of course argue that such a “ditto mark” would lean to much on the human side – not sure… |
Beta Was this translation helpful? Give feedback.
-
|
Oh sure. I obviously only grep the last occurrence (which happens to be the most recent one). I am definitely not using all the features of klog. I agreed also about the balance between human readability and parse-able data, but whenever I can, I flee away from cosmetic variants as I find them real source of problems. All in all, I did not add "my" feature the proper way - which would be in the go source and benefit from existing parser routines. Just to give you some context and you get the idea, my journal is pretty basic and strictly follows to a policy of mine which is narrower than what klog can do. Every entry is a single line like I can easily collect the unique #tags : #vlz and #oomade below which happen to be my clients (by policy) I also sub-categorize my times with the first word that follows the tag (here "free" and "doc" for client #oomade, and "sfl" and "doc" for client #vlz) ... Klog was most probably designed with the idea to have one journal per client, but I prefer having only one journal file for all my activity, and send only the relevant extracts to my clients. So I shifted the concepts : one journal, one tage per client, one word for tags (which gets re-coded when the journal extract is built by my wrapper). Eg: It was built exclusively with my little wrapper:
From there, I can: Or when I want to bill one client without letting him know about the others : Sorry for being this verbose. Be sure I would easily understand that my request gets you offtrack ;) |
Beta Was this translation helpful? Give feedback.
-
Imagine the case when you work on multiple things throughout the day:
Especially if you want to tag your entries, then it can be tedious since you have to repeat the tags for all respective entries. You cannot put the tags into the overall record summary, because then the tags would apply to all entries.
In a physical notebook, you probably would use some sort of ditto mark notation, to indicate that you want to take over the previous sentence.
Proposal
I’m wondering whether this idea could also work in klog, where a special placeholder mark could indicate that the previous entry summary should be taken over. The example below demonstrates different placeholder ideas,
^,", or---"---. (In the end, there would only be one, of course.)Similar to the open-range placeholder
?, it probably makes sense that the marks can be freely repeated for aesthetic/alignment reasons:Discussion
Of course, there would be some complexity to this, and a few questions would need to be resolved:
5h Foo^or5h ^ ^ ^ ^or5h ^^^ foo5h ^ #additional-tag(i.e. “all of the above, plus the text that follows”)References
klog start/klog stopGeneral Considerations
All in all, I run into this problem frequently enough that it keeps me thinking. On the other hand, I see high value and priority in keeping klog simple and straightforward, especially in regards to the file format syntax. So I would only want to add something like this if I’m convinced that the concept is meaningful and works well.
Beta Was this translation helpful? Give feedback.
All reactions