Parsing of logged time in :LOGBOOK: drawers with comments fails

[munen]

Clocking time within organice and saving it in a :LOGBOOK: drawer is a new feature (See #103).

It works fine, unless the clocked time is intervoven with comments in which case the parser crashes here.

According to the Emacs documentation, "can contain anything but a headline and another drawer", though.

A first test case (added to logbook.org) for this could be:

* Logbook with comments within the clocked times
  :LOGBOOK:
  CLOCK: [2019-11-21 Thu 21:12]--[2019-11-21 Thu 21:12] =>  0:00
  Here's another comment
  CLOCK: [2019-11-21 Thu 21:12]--[2019-11-21 Thu 21:12] =>  0:00
  CLOCK: [2019-11-12 Tue 14:15]--[2019-11-12 Tue 13:20] => -0:55
  There's a comment
  CLOCK: [2019-11-12 Tue 14:15]--[2019-11-12 Tue 14:25] =>  0:10
  :END:

[munen]

The issue was first found by @Linuus in this ticket: #108

[munen]

@jamesnvc Since you've build the initial version of clocking time and hence might be interested, I'm pinging you here. Of course, there's neither obligation to work on this or even answer to this message. If you're not interested, please just ignore the notification and be sure that I'm sorry about cluttering your inbox(;

[jamesnvc]

Oh yes, I ran in to that on some of my own data; I'm happy to work on a fix

[jamesnvc]

Would removing the "invalid" data be acceptable?

[Linuus]

Would removing the "invalid" data be acceptable?

There’s nothing invalid about the data so please do not remove anything? :)

[munen]

@jamesnvc

Would removing the "invalid" data be acceptable?

Generally speaking, I'd say that parsing without crashing is good. However, for this specific case, I'd have the following two arguments:

• One goal of organice is not to alter existing Org files so that there's no diff when using Emacs and organice. That's a big differentiator to me compared with alternative tools.
• More importantly for this specific issue: This is clocked time. If people use Emacs to track their time, this could for example be for billing customers (I assume, because I do generate my invoices from it^^). If people use comments in between the clock entries and we remove them, they might not catch it and lose the ability to answer the rudimentary question on what they worked at a specific point in time. So in this case, I'd actually rather that organice crashes instead of losing data(;

Imo the best approach here would be a very aggressive regexp to check every line on whether or not it's a clock entry. If it's not, it can be saved and re-exported verbatim.

As a bonus, this other clocking related parser issue (#110) would also be solved(;

I'm happy to work on a fix

This is great news. Thanks for jumping into the discussion less than half an hour after a ping. There's an amazing community forming here. I'm stoked. Thank you everyone! 🙏 🙇

[munen]

Fixed by @jamesnvc in PR #112. 🙏