due and overdue syntax highlights

[linuxcaffe]

Of the 256 colors taskwarrior is capable of, the two I miss the most are the subtle background (in my colors, anyway) representing "due" and "overdue".

This breaks a due: sorted list into three groups, indicating an "alarm" condition (overdue) a "normal" condition (due) and a "low pressure zone" (not yet due) and the best part is the line between due and overdue is obviously "now".

This highlight gives instant meaning to a column of dates, and even when sorted other-than due: it is still a helpful visual clue.

[blindFS]

I wanted this feature too. But this will greatly slow down the reaction speed. Maybe it will be much faster if there is a available column showing task type(waiting/due/overdue/blocking..... anything related to the color) .

[linuxcaffe]

There isn't really such a column-type, and perhaps one could be cooked up, but it would cost extra screen real-estate and not be immediately apparent as a condition of "due:".

:-/

A vim thing I'm just learning about "signs", I barely grasp them, and even less how that might apply, but author Christian Brabandt, who has recently done some brilliant work with task-theme-file highlighting, [1] also wrote a plugin; https://github.com/chrisbra/BackgroundColor.vim that uses vim signs to color backgrounds.. obviously :)

Like I say, I have no real idea if this is applicable or not, but thought I'd point it out for consideration.

[1] https://github.com/chrisbra/color_highlight/issues/26

[blindFS]

The problem is not how we highlight them. It's how can we tell which ones should be highlighted in which way. And any possible method I can come up with is slow enough.

[linuxcaffe]

As to "which way", Identifying "overdue" is easy, due.before:now, As for "due" I would probe taskrc for the "due" value, but the default is "7" days from now.

Is a due.countdown or due.age any better to parse?

it seems to me that due.age > 0 is overdue, due.age between 0 and -%taskrc_due is due

[blindFS]

No, when I say which ones, I mean which lines in the report, not which uuids. And the main procedure that affects the performance is mapping ids to line numbers.

[linuxcaffe]

I'm way over my head at this point, but I posed the problem on irc.freedode.net #taskwarrior, and a helpful user suggested a look at Tim Pope's SpeedDating, to see how he does high-performance date tricks. https://github.com/tpope/vim-speeddating.

again, this may or may not be relevant, but just looking at due-column and date, ignoring ids and uuids... like I say.. idonno :)

On 23 November 2013 02:41, zc he notifications@github.com wrote:

No, when I mean which ones, I mean which lines in the report, not which uuids. And the main procedure that affects the performance is mapping ids to line numbers.

— Reply to this email directly or view it on GitHubhttps://github.com/farseer90718/vim-taskwarrior/issues/70#issuecomment-29127890 .

[linuxcaffe]

yeah, now I see speeddating is excellent and unrelated (?) :-/

On 23 November 2013 12:44, David J Patrick davamundo@gmail.com wrote:

I'm way over my head at this point, but I posed the problem on irc.freedode.net #taskwarrior, and a helpful user suggested a look at Tim Pope's SpeedDating, to see how he does high-performance date tricks. https://github.com/tpope/vim-speeddating.

again, this may or may not be relevant, but just looking at due-column and date, ignoring ids and uuids... like I say.. idonno :)

On 23 November 2013 02:41, zc he notifications@github.com wrote:

No, when I mean which ones, I mean which lines in the report, not which uuids. And the main procedure that affects the performance is mapping ids to line numbers.

— Reply to this email directly or view it on GitHubhttps://github.com/farseer90718/vim-taskwarrior/issues/70#issuecomment-29127890 .

[blindFS]

I have not tried to parse the date string and compare. But it still requires iterating through and get due field for each line(which is already a heavy burden I guess).

The most important point is, this approach is so limited that it can't tell other task type such as blocking,waiting.

[linuxcaffe]

I had an idea about apply taskwarrior colors that was so brutal and crude, that I wasn't going to mention it, but now I wonder how it would compare to parsing dates.. so .. with that caveat, let me describe it;

a) task rc._forcecolor:1 rc.verbose:off list proj:foo > foo-file.txt

and foo-file.txt will be full of color codes, but what if it were run through something sed-like, that stripped everything but the first color-code, and the last color-code of each line, so if the report were 11 lines long, the result would be 11 pairs of color-codes.

b) Run this (streamlined) process in parallel to each taskwarrior#list, the second iteration just to harvest the color codes, and tack the codes onto each line and vois la! taskwarrior theme in vim-taskwarrior!

c) Go hang your head in shame for such a slow, dirty hack! ;-)

[blindFS]

I think the taskwarrior highlights the output according to the urgency value?

[linuxcaffe]

Actually, tw highlights with a fairly complex scheme; it's combination of color rules and precedence order-of-execution.

first color-rules are assigned from the default theme or an included theme file, that looks like this;

http://tasktools.org/gitweb/?p=task.git;a=blob;f=doc/rc/dark-256.theme;h=ae5a60116832a07a6c2f88b9197f5c700d11045f;hb=HEAD

or just run "task show color"

and then those colors are applied in order of "precedence" which can be seen with "task show precedence" (or using _get) and looks like;

djp@yang:~/.vim/bundle/vim-taskwarrior$ tw show precedence

Config Variable       Value                                                                                                                      
rule.precedence.color due.today,active,blocking,blocked,overdue,due,scheduled,keyword.,project.,tag.,uda.,recurring,pri.,tagged,completed,deleted

In theory, only the rule with the highest precedence will be applied, in practice, the best effects assign foreground-color to one aspect and background-color to another aspect, and the results can have a combination of bg-rule applied for one-thing and fg-rule applied for something else.

It sounds fairly complicated, because it is. I personally don't much like the stock set of themes, because there are a couple of arbitrary assignments, and it misses some opportunities to be informative, but I'm cooking up a second-generation set that I think are actually helpful and effective, not just colorful.

[linuxcaffe]

Also, see recent taskwarrior theming news; http://taskwarrior.org/news/182