The color extension is ignored when a style is specified, either using the --style command or in .hgrc. REPRODUCTION 1. Enable the color extension by including the following in ~/.hgrc [extensions] color= [color] log.changeset=yellow 2. Run "hg log" and "hg log --style=default". Then add "style=default" to ~/.hgrc and run "hg log" again. EXPECTED BEHAVIOUR Changeset line of log output is highlighted in yellow in all three "hg log" commands ACTUAL BEHAVIOUR Changeset line of log output only highlighted if no style is specified on the command line or in .hgrc configuration. If a style is specified then all color preferences are ignored. NOTES You may say, "well, don't specify --style=default!" Unfortunately this is a problem because my goal is to tweak the default template. I made a copy of the template, called it map-cmdline.default2 and whether I do hg log --style=default2 or add style=default2 to my ~/.hgrc, the color highlighting is disabled.
That is certainly true but is also unlikely to change due to the architectural difficulty of passing the out-of-band style information that the color extension uses through the pure text templating engine. Degrading to wish.
This should be noted in the manual if it is not a bug.
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:21 EDT --- This bug was previously known as _bug_ 2866 at http://mercurial.selenic.com/bts/issue2866
The template extension now works with color. All that remains are for the appropriate label() clauses to be added to the existing templates by copying the labels used in the stock changeset printer: http://www.selenic.com/hg/file/54ff2789d75e/mercurial/cmdutil.py#l860 self.ui.write(_("branch: %s\n") % branch, label='log.branch') becomes something like: branch: {label("log.branch", branch)} in mercurial/templates/map-cmdline.*
Fixed by http://selenic.com/repo/hg/rev/0ded0f0b1c04 Jordi Guti?rrez Hermoso <jordigh@octave.org> log: rewrite default template to use labels (issue2866) This is a complete rewrite of the default template to use labels. This seems ultimately useless to me in most cases. The biggest benefit of this patch to me seems to be a fairly complicated example of the templating engine. It was a lot of hard work to figure out the precise acceptable syntax, since it's almost undocumented. Hat tip to Steve Losh's smartlog template, which helped me figure out a lot of the syntax. Hopefully later I can use the present default log template as an example for documenting the templating engine. A test is attached. My goal was to match the --color=debug output, which may differ slightly in newlines from the actual ANSI escape codes output. I consider this an acceptable invisible deviation. There seems to be a considerable slowdown with this rewrite. Before: $ time hg log -T default -r .~100::. > /dev/null real 0m0.882s user 0m0.812s sys 0m0.064s $ time hg log -T default -r .~100::. > /dev/null real 0m0.872s user 0m0.796s sys 0m0.068s $ time hg log -T default -r .~100::. > /dev/null real 0m0.917s user 0m0.836s sys 0m0.076s After: $ time hg log -T default -r .~100::. > /dev/null real 0m1.480s user 0m1.392s sys 0m0.072s $ time hg log -T default -r .~100::. > /dev/null real 0m1.500s user 0m1.400s sys 0m0.088s $ time hg log -T default -r .~100::. > /dev/null real 0m1.462s user 0m1.364s sys 0m0.092s Following the maxim, "make it work, profile, make it faster, in that order", I deem this slowdown acceptable for now. I suspect but have not confirmed that a big slowdown comes from calling keywords twice in the file templates, once to test the existence of output and again to actually list the output. If so, a simple speedup might be to improve the templating engine to cache keywords when called more than once on the same revision. TODO: I found a bug while working on this. The following stack traces: hg log -r . -T '{ifcontains(phase, "secret public", "lol", "omg")}\n' (please test the fix)
Bulk testing -> fixed