2016-03-24 Beeminder.el – a follow-up

Some time ago I wrote about a Beeminder client I wrote for Emacs. I mentioned then that I want to make it a bit more sophisticated. And so I did. Since then, it got quite a few features.

One of them is displaying and editing datapoints. You can now press TAB on a goal and a bunch of information about that goal – including a few datapoints – will be displayed. (By default, one week’s worth of data is downloaded and displayed.) You can press n and p to navigate between datapoints (of course, normal Emacs movement commands work, too!) and press e on a datapoint to edit it.

Another one is that I decided to switch to asynchronous http requests. I got tired of waiting for my goals to update etc.; also, with async requests, I couldn’t (or maybe I didn’t know how?) to handle errors gracefully.

Yet another concept I introduced is everyday goals. These are goals which shouldn’t be filtered out, even if you only want to see goals derailing within the next n days. The idea is that, on the one hand, you want to be able to have some buffer for those goals, but on the other one, you want to be reminded about them. For instance, I want to update my ledger each day, but I it’s not a terrible thing if I miss a day here and there. Therefore, my setup looks like this: the daily rate of 0.8, max safe days equal to 2, and the goal included in my “everyday” list. This way, even if I have a 2-day buffer (and I usually do), and I display only the goals with 0 days to derailment (aka, “things I have to do today”), I will see it. Of course, this is configurable, and switching it off is a question of pressing one key.

Finally, it is now possible to submit all clocks in the Org subtree or region. By default, only clocks from last 24 hours are submitted (this can be changed globally via a user option or locally via prefix argument). Also, submitting clocks (whether individual or in bulk) is now idempotent, i.e., submitting the same clock twice doesn’t change anything. (The idempotency key is the combination of start and stop times, though due to how Beeminder works, two datapoints with identical key for two distinct goals are possible.)

There are many more things, mostly bug fixes and small improvements (like logging all Beeminder-related events in a dedicated buffer, displayed with L – this became rather necessary with the introduction of asynchronous requests). The code is now more or less stable, and even though I plan to tinker with it a bit more (and I have a few features in mind, too, though they are not critical), I will probably more or less move to greener coding pastures. (Also, I now work a lot on my contest project.) Still, here is a short to-do list.

If you happen to use my client, and really want to have some of the above features (or something else entirely), drop me a line – I’ll see what I could do.

CategoryEnglish, CategoryBlog, CategoryEmacs, CategoryOrgMode