Re: Extending timeclock.el

[Philip Kaludercic]

John Task <q01@disroot.org> writes:

> Hello.  A little context, first; some days ago, I submitted a request
> for including a package in the NonGNU ELPA repository.  The package in
> question was a time tracker named ETT.  However, Eli pointed out that
> instead of creating a new package I could, for instance, extend the
> built-in timeclock.el instead.  To be honest, I didn't like the idea
> at first, but looking at the code I quickly realized it wouldn't be
> that hard.  At least, not as dramatically hard as I thought.
>
> So I started this: https://gitlab.com/q01_code/timeclock-modern
>
> [This wasn't my first name choice, but turns out timeclock-x is
> already taken]

By whom?  I couldn't find anything.

> So far, I managed to write a series of parsers for the timelog format,
> as well as a basic API for retrieving information from it.  This
> should allow me to port all the relevant code from ETT without issues.
> However, I'm not really familiarized with timeclock, so I can't assert
> my design choices so far have been ideal.
>
> + The letter code at the start of every line was the most difficult
> part.  ETT (and a lot of modern time trackers as well) don't
> understand what clock-out means, as the idea is to clock everything;
> the user just clocks-in different activities.  So, I dropped 'i' and
> 'o' for my custom tm-clock-in altogether.  As for the parser, it
> understands 'o' as the start of a so-named 'Untracked' item/project.
> That way it can read existent timelogs just fine.  This is hard
> enough, but turns out there are also other codes ('h', 'b' and '0').
> I interpret '0' as an 'o' and ignore the other ones, but I'm not sure
> if this is correct.
>
> + As I make a lot of decisions such as the last one from ignorance,
> I'm clueless about how well the parser (and the API) works for real
> timelog files.  If anybody wants to test that, it would be
> appreciated.
>
> + As the original timeclock-in doesn't support inputting tags (as well
> as other features I need), I wrote a custom tm-clock-in.  But I'm not
> sure if this is the right approach.  And redefining timeclock-in would
> be even worse, for sure.
>
> I'll eventually contact the original author as well, but I wanted to
> know of any other opinions here first.
>
> Best regards.

-- 
Philip Kaludercic