[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