[PATCH 2 of 6 RFC] templater: wrap each parsed element with a label filter

Matt Mackall mpm at selenic.com
Fri Dec 28 15:55:39 CST 2012


On Mon, 2012-12-24 at 01:03 -0600, Sean Farley wrote:
> # HG changeset patch
> # User Sean Farley <sean.michael.farley at gmail.com>
> # Date 1356234924 21600
> # Node ID 75ef781d20973d036f003bba00a873bf1c5d5598
> # Parent  54276c120146e14cc4ab931b799c94bd671ee524
> templater: wrap each parsed element with a label filter

I tried to make this clear earlier, but apparently I failed. Let me try
again: any solution that adds complexity to the core of the templater to
enable colorization will be rejected as not-worth-it. This does that,
thus it is rejected. 

Here's a measurement without the first two patches:

$ time hg log --style default -r 0:10000 | wc
  53202  211795 1914499

real	0m2.116s
user	0m2.073s
sys	0m0.033s

And here's one with:

$ time hg log --style default -r 0:10000 | wc
  53202  211795 1914499

real	0m2.500s
user	0m2.450s
sys	0m0.040s

That's about a 20% penalty on all templating (including hgweb!) for a
feature that only even does anything on the command line when color is
enabled and I/O isn't redirected. Not a good trade-off.

Let me also be explicit that the entire class of solutions that try to
track the 'class' of data through the templater are also rejected.
They're too complex, the defaults are semantically wrong anyway, and
it's not-worth-it.

Please send a patch series that:

- adds a no-op label(label, expression) method (note the argument order)
- overrides it in color.py

-- 
Mathematics is the supreme nostalgia of our time.


-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list