Timeline for Org: Show Clocked Time hour-by-hour
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 3, 2016 at 20:15 | comment | added | dfeich | @tobias and nagora: Thanks and welcome. I noted that Tobias has made a number of nice additions, e.g. the summing of the same task within a single hour. I also learned from his edit of my post how to have the elisp code marked up correctly here on StackExchange. Thanks! | |
| Mar 3, 2016 at 17:13 | history | bounty ended | Nagora | ||
| Mar 3, 2016 at 17:05 | vote | accept | Nagora | ||
| Mar 3, 2016 at 17:05 | comment | added | Nagora | @dfeich I'm giving you the tick because I've found the code easier than Tobias' to alter to suit some other needs I had which were relatively minor. It's saved me a lot of pointless effort. Thanks. | |
| Feb 29, 2016 at 19:11 | comment | added | Tobias | I've noted the summing of the minutes of the same project in the same hour in your version and adapted this to mine. Thanks. The clock items for different projects are not sorted with respect to each other. Therefore, I first collect everything and then sort w.r.t. the beginnings of the clock ranges. The sorting has n*log(n) costs all other things have costs of order n (even parsing). I work on the sorted list. I dismiss work items that end in the hour. I increment the hour only if there are really work items there else I take the hour of the first item in the (remaining) list as next hour. | |
| Feb 29, 2016 at 11:51 | comment | added | dfeich | @Tobias: I have not profiled, and it could well be that it is no big thing performance-wise for normal files. I need to look into the caching mechanism which seems interesting. I wrote the function in the way I did in part for my own usage where I have org docs with items accumulating clock information over 1-2 years. Since clocked times are progressing from newest clock interval to oldest, you can stop parsing once you reach a clock no longer in your target time interval, instead of parsing the whole. | |
| Feb 28, 2016 at 17:33 | comment | added | Tobias | The org parser works with caching and should not introduce too large performance losses. I did not check how far the caching reaches. For an instance: I do not know whether org has a partial parser such as cedet/wisent. With such a partial parser it is not necessary to reparse the whole document if some part of it has been edited. | |
| Feb 28, 2016 at 17:24 | history | edited | Tobias | CC BY-SA 3.0 |
Just formatting the source code as elisp.
|
| Feb 28, 2016 at 16:04 | history | edited | dfeich | CC BY-SA 3.0 |
Tried to clarify how to use a dynamic block. Unsure wheather users has experience with that.
|
| Feb 28, 2016 at 16:03 | comment | added | Nagora | Thanks. An embarrassment of riches. We had a meeting with the management on Thursday where the whole development team complained about the format but they would not budge. | |
| Feb 28, 2016 at 15:25 | history | answered | dfeich | CC BY-SA 3.0 |