Taskwarrior

Done

sorry for re-opening, but I'd like to suggest that this good idea go farther, and be re-imagined not as "today" but "now", so that is it contextual. Looking at the cal output ? then both this datenumber and this monthnumber qualify as "now". Looking a a task report output ? if rc has "color.due.now=on_color128", it makes sense to see the same color in any view of tasks due "now" whether zoomed in to a 4 hour block (not yet possible), looking at a report or backed out to a multi-month view.

I admit that I'm not sure where Fredde's new cal colors are defined, but I think they should be in with the general population. There will be a real value in color consistency between views; cal and report (and those to come)

The new cal colors are defined in .taskrc, and all are properly named "color.xxxxxx". If you regenerated a sample .taskrc, as discussed recently, then you already have them. If not, just run:

task config

and you'll see them go scrolling by. There is also the option of Reading The Formatted Manual:

man taskrc

Excellent! and darn those man pages are good !

color.calendar.today=black on cyan

   Color of today in calendar.

is the parameter in question, but what I was musing about was whether that rule might be replaced with a directive like

color.now=black on cyan

and that setting be allowed to scale according to view; the calendar day, monthname, tasks due.today in a report, highlighting today in a future week-view, scaling down to the smallest increment seen, as in "this hour" (when hours are supported) basically a consistent color representing "now" in whatever time-scale is seen.

Glad you have it. I just love to tell folks to RTFM, particularly after the effort put into the FM.

Regarding the re-opening of this issue: If this were originally a bug closed for 1.9.0, and a problem were found, then re-opening and reassigning the bug to 1.9.1 would be the right thing to do.

As this is a feature that just shipped in 1.9.0, and has no associated problems, combined with the fact that you are proposing new functionality which extends this capability, I think it should be a new issue, and this should stay closed. I realize that the new functionality is related and may supercede this, but by re-using the issue, we somewhat lose track of the original work.

I'll open up a new issue later, and restore this one.

Also, I like the new idea.