[TW-86] Color rules should be triggered by complex conditions, not just single values

[taskwarrior]

Paul Beckingham on 2011-04-03T15:52:35Z says:

Color rules should be more flexible, and support arbitrary expressions (conditions) as triggers, such as:

start.any: AND +tag

This means that the current color rule syntax needs to be changed.

Thanks to Jose Quesada.

[taskwarrior]

Migrated metadata:

Created: 2011-04-03T15:52:35Z
Modified: 2014-12-27T15:53:46Z

[taskwarrior]

Paul Beckingham on 2011-06-25T17:27:29Z says:

This needs to be designed.

[taskwarrior]

Jim B on 2013-08-26T16:34:38Z says:

I'll second this feature request. It would be very helpful towards a nice implementation of 1MTD and MYN (http://taskwarrior.org/boards/8/topics/2977). For now I might use some compound shell commands to achieve similar, albeit suboptimal, results. :)

[taskwarrior]

David Patrick on 2013-08-28T00:58:03Z says:

This is an opportunity to plug a small log colorization program called "clog" written by Paul Beckingham. (yes, THAT pbeckinham, principal author of taskwarrior)

http://tasktools.org/projects/clog/

Paul wrote clog some time ago as a small personal utility to colorize his logs, really just to automate a repetitive chore, and in the process he created an easy-to-use regex-driven colorization utility that can be used for all sorts of stuff, including enhanced task colors with custom rules.

I did some testing and had some success applying clog color-rules to forcecolor=on task output, and I liked it a lot, saw real visual improvements in clarity, but eventually got tired of the cli-workarounds to make it play nice.

After several rounds of annoying questions by me, Paul suggested that rather than smarter workarounds, the best thing would be to integrate the regex-rule-based clog functionality directly into a future version of taskwarrior!! (YES!) because writing both programs, it wouldn't be all that hard.

So I wanted to mention to those craving more color, that there is an absolute rainbow on the back burner, and I wanted to remind Paul to start thinking about how tha merger might happen.

Try running clog and you'll immediately see how colorful taskwarrior's future could be

[taskwarrior]

Paul Beckingham on 2013-08-29T14:44:06Z says:

I'm collecting notes on this. I would like the feature too. I think there are three areas that need to be addressed:

1. Regex support, because, why not?
2. Logic support means we need to evaluate arbitrary expressions (pending AND (priority:H OR +bug) --> make it red)
3. Better color composition, giving control over individual characters, instead of the whole task

This depends on the 2.4.0 parser update, which will have an improved expression evaluator. I'm concerned about performance , applying multiple rules to all tasks on render. It's going to be a challenge.

[taskwarrior]

David Patrick on 2013-09-01T01:53:17Z says:

here's a screenshot of some test-colorization on both task and taskopen output.

The top is after clog, the bottom is untreated.

I think you'll agree that the top ones are WAY easier to read!

The enhancement was achieved by piping forcecolor=on to clog, having set up .clogrc. My command (with alias) looked like;

$ twc proj:tw |clog

and the .clogrc entries looked something like (but not exactly like);

1. ## clog rules file 
1.  Notes
default rule /Notes: / --> rgb351 match
1.  calls
default rule /call|phone/ --> color11 match
1.  exe: 
default rule /exe:/ --> color1 match
1.  test
default rule "things" --> rgb501 match
1.  KEYWORD_TXN
default rule /txn|pay|buy|deposit|withdraw|transfer|invoice/ --> rgb400 match
1. default rule /\.|\/|~/ --> blue match
default rule /\s(~?\/)(\w*\/)*/ --> magenta match
1.  taskopen selection numbers
default rule /^ +[0-9]+\)/ --> green match
1.  taskopen description (or anything in parens)
default rule /\(.*\)/ --> gray10 match
1.  double dashes (not leading, as in --long-form-command)
default rule / \-\- / --> green match
1.  taskopen IDs
default rule / [0-9]+$/ --> bold match
1.  web links (root only) protocol should be separate match
default rule /www\.\w+\.(com|org|net|ca)/ --> blue match
1. default rule /^([\w-]+\.)+[\w-]+(/[\w-./?%&=]*)?$/ --> blue match
1. default rule /^(http(s?)\:\/\/)*[0-9a-zA-Z]([-.\w]*[0-9a-zA-Z])*(:(0-9)*)*(\/?)([a-zA-Z0-9\-\.\?\,\'\/\\\+&%\$#_]*)?$/ --> blue match
1. default rule /[a-z0-9]+([\-\.]{1}[a-z0-9]+)*\.[a-z]{2,5}/ --> blue match
1. default rule /www\.[a-zA-Z0-9\-\.]+\.(com|org|net|mil|edu|COM|ORG|NET|MIL|EDU)/ blue match
1.  I modified it slightly to allow ip addresses and localhost for my own use: ^[a-z0-9]+([\-\.]{1}[a-z0-9]+)*\.?[a-z0-9]{2,5}$ 
1.  dates
default rule /[0-9]{1,4}\/[0-9]{1,2}\/[0-9]{1,4}/ --> cyan match
1.  filepath (but not the file) magenta match
1.  UUID (long and short) color1 match
default rule /[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4})-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}/ --> red match

Including some mysterious cut-and-paste, some mistakes and experiments, because I'm a regex reject! ;-)

[taskwarrior]

David Patrick on 2013-09-01T15:29:18Z says:

Just to beat this colorful horse a bit more, while pb was suggesting full regex-color integration, I would favor the extension approach, and making tw clog-aware.

With a clog-extension, that comes with default tw configs, an .rc entry;

use_clog=yes

or

include /home/djp/.clogrc

or

include $TASKDIR/tw.clog

could have the desired effect.

The extension might be better because a) won't hideously complicate the core b) regex-colors will slow down execution considerably c) then other tw-related scripts can be piped through the same .clog file d) no major re-write required of clog or tw

[taskwarrior]

Paul Beckingham on 2013-09-01T15:48:17Z says:

Nice screenshots. Those are compelling. I want to respond to the clog approach:

a) won't hideously complicate the core

There will be additional complexity, but then again, the current limited color rules system is 400 lines of code, and not structured well. For a fair comparison, you have to include the size of clog, which is 600 lines if you ignore the shared code with tw. So for a total 1000 lines of code, I feel we could have a dramatically better rule system.

b) regex-colors will slow down execution considerably

True. But the rules system is not all-regex, there are keywords and values as well as regexes. Features like this will incur a performance hit only if you use them, which is the fairest way to implement an expensive feature, and something we do elsewhere in tw. Plus, the performance trend for hardware, os, terminal and tw is upwards.

c) then other tw-related scripts can be piped through the same .clog file

There is nothing preventing this approach today, which is nice. That is, after all, what clog is for.

d) no major re-write required of clog or tw

Clog would be untouched. Tw would get a new compositor (which it needs for charts), and a rules-system rewrite. Still a major work, but not as big as some other efforts.

[taskwarrior]

David Patrick on 2013-09-01T18:24:39Z says:

that worksforme!

[taskwarrior]

Max Muller on 2013-11-06T16:48:53Z says:

I want to point out that this feature request is ALMOST IDENTICAL IN CONCEPT to the proposed feature [[#1122]], except that this one is requesting complex rules for assigning COLOR, and [[#1122]] is requests complex rules for assigning URGENCY.

Given their similarity, I wonder, if either feature is implemented, could the other be as well? Could the solution be designed with both in mind? There an opportunity here for some great consistency between two powerful new features.

[taskwarrior]

Paul Beckingham on 2013-11-06T18:43:00Z says:

Given their similarity, I wonder, if either feature is implemented, could the other be as well? Could the solution be designed with both in mind? There an opportunity here for some great consistency between two powerful new features.

Yes Max, that is the hope.

This happens often - we accumulate several related requests, and through the power of sloth, do nothing about them for a while. During this time the ideas improve and mature. One day we decide to make a large sweeping change that closes many issues at once.

So following that lead, what we need is a plan for some kind of sophisticated rule processing, that doesn't incur a terrible overhead, and offers some way forward without requiring another rewrite in the near future.

My assumption is that we need a rule DSL that allows us to define simple rules:

"make all overdue tasks red"

And more complex cases:

"make tasks with a set of certain qualities lighter in color"

Then that naturally leads to the option of doing more than just affect color:

"If a task is late and unblocked, in one of these projects, not tagged as a bug, then add the +notify tag and assign it to the today project"

... And suddenly we're talking about hooks and extensions. I think this deserves to be part of a larger extension mechanism where actions are triggered by conditions. This is major work and needs a champion.

[taskwarrior]

Max Muller on 2013-11-07T15:57:34Z says:

and through the power of sloth

I don't think sloth afflicts anyone involved in this project. Thanks for the awesome, ever-evolving Taskwarrior!