block: taskwarrior

[rosshadden]

Make a block for taskwarrior.

Not sure what all should be present. Probably next task(s), and an alert icon if you have unsynced tasks.

[tshirtman]

:+1:

[tshirtman]

i have this https://gist.github.com/tshirtman/dd2cc5a068b4679023b2

the scripts run correctly independently, but somehow, the results are empty when ran by i3blocks, that's strange.

currently it tries to show active tasks (with description) and overdue tasks (only ids)

[tshirtman]

actually, it works (updated), i just had a path issue due to how i installed taskwarrior.

[rosshadden]

@tshirtman thanks for taking a stab at this! If you want to try to make it match a similar coding style to our other blocks, I would be happy to accept a merge request with your addition.

I'm not sure how we should best handle defining a path to task. What you had in your first version (just task) would work for me and anyone that installs taskwarrior at the system-level. But it obviously didn't work for you, because you had to define the path to it yourself.

I'm open to suggestions, but it looks like hardcoding it to either will be insufficient. Whatever we do should probably be applied to our other blocks as well. Any ideas @oppenlander ?

[oppenlander]

It might be nice to keep your .local path seperate, but I don't think it's unreasonable force the user that runs i3blocks to have the necessary tools in their PATH. i3blocks does support passing instance information through the BLOCK_INSTANCE variable, but we've been reserving this for things like interfaces and formatting strings.

Speaking of format strings, that could be a good addition. We could come up with a format language for task types, like:

[taskwarrior]
instance="active (%a) done (%d)"
interval=30

So the same block script can be reused to display different Task Warrior information.

[rosshadden]

I like the format syntax idea. Also I agree, I would prefer to force dependencies to be in the user's PATH, and refer to them directly as we are doing in the other blocks.

[tshirtman]

First, yeah, i agree the script shouldn't have to care about the path to task, worst case, confusing users like me can edit their copy and fix that path, or they can, maybe, fix their env for sh.

Also, the way this work is certainly hacky and fragile, i have to investigate the json api of task, instead of abusing an output that is formated in a very un-computer-friendly way.

That format string idea sounds awesome :), easy to define a few functions for each part, and call them depending on the string's content.

Ah, and i have to update the gist again, i was told that it was safer to set rc.gc=off in the command if i was calling task often, and possibly while other task operations happened, so.

task="task rc.gc=off"

would be the new value.

[rosshadden]

What does rc.gc=off do? Depending on what it does, it might not even be necessary. I would think most people would use this block with a pretty high interval, as the number of tasks don't change all that often. I would personally set the interval to be very high (or even -1, which turns it off), and rely instead on using signals.

[tshirtman]

hm, had forgotten about signal, indeed, it would be better. rc allows to change a conf option at run time, and gc is some kind of reorganisation of the tasks, so their id can actually be changed when that happens, gc=off supposedly avoids that.