color.uda.priority.L being taken over higher precedence active even when rule.precedence.color is set

[chamons]

To report a bug...

• What command(s) did you run? With this configuration:

  
  include /usr/share/taskwarrior/no-color.theme

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

urgency.user.tag.blocking.coefficient=6

color.active=rgb410 color.tag.PR=rgb035 color.uda.priority.H=rgb542 color.uda.priority.L=gray6

and these task:

ID Active Age P Tags Description Urg 11 1min 1min L test Test-Active 6.6 12 1min L test Test-Low 2.6 10 1min test Test-M 0.8

* What did you expect to happen?

I expect Test-Active to be orange (color.active) as active is later in the priority list. (This also happens if uda. is at the end of the list). 

* What actually happened?

However it is gray (color.uda.priority.L).

The order of the rules does not seem to matter.

![image](https://user-images.githubusercontent.com/6392201/113602185-ed978600-9607-11eb-9dbd-e7b446e7be0d.png)

* Paste the output of the ```task diag``` command.

https://gist.github.com/chamons/0aeb0b49ef5f7f6301a618932691f506

[chamons]

I'm now having difficult with an active task without any priority not having color.active taken, so maybe it's a bug there any not precedence?

I'm very confused what's going on here.

[sebu06]

Hi, for me it seems like the order of the precedence ist is the opposite than what you've expected, i.e. the highest precedence is first in the list:

rules.cpp:283
  for (auto r = gsPrecedence.rbegin (); r != gsPrecedence.rend (); ++r)

and at least for me everything works as expected in your case if I reverse the precedence list.

[tbabej]

@sebu06 You might be onto something here. This problem rings a bell for me.

[sebu06]

Which would be the correct order of precedence? I think it simply depends on the definition and if it should be the other way around, then in my optionion simply rbegin() would have to be changed to begin().