[PATCH 2 of 3] templater: add len template filter

[Anton Shestakov]

09.09.2014, 11:03, "Mads Kiilerich" <mads at kiilerich.com>:
> On 09/08/2014 02:04 PM, Anton Shestakov wrote:
>>  # HG changeset patch
>>  # User Anton Shestakov <engored at ya.ru>
>>  # Date 1410176607 -32400
>>  #      Mon Sep 08 20:43:27 2014 +0900
>>  # Node ID 82b3cffda4868d23ce436adac8687645f5f7441b
>>  # Parent  9bb0ab35e90ac9ebf6adbd6e503f3412d9f2adb7
>>  templater: add len template filter
>
> Most excellent, thanks!
>
> I had thought about implementing something like this and call it "count"
> instead. I am not sure I like that this approach exposes whatever python
> len does ... but I guess it is ok and can be handy.

Thanks for the feedback! I've named it len because you can call filters just
like functions too, i.e. {len(revset(...))}, which arguably looks more pythonic
than count(), but since templates are not python anyway, I have no problem
renaming it. (Which reminds me of django templates, which are so frustrating at
times exactly because they look much like python, but are not. Let's not bring
that here.)

> The combination of log and revset and len is very powerful (and
> potentially slow). I think that combination also should have some test
> coverage. Perhaps by adding root distance: {revset("::%d",rev)|len} .
>
> Personally, I would prefer to have the test in the same changeset as the
> code so it helps documenting why the change is made. That makes history
> digging so much easier.

Sure, I will do that in the next version of the patch.

> I guess templatification of "id" will make that a better way to get the
> size of a revset result ... but a dedicated 'count' command could
> perhaps also be handy.

Yes, I've decided to make this filter after trying to imitate summary command
with one big template. That's turned out to be a mess when I got to label()ing
every line. So I think that templatificating identify instead is a great idea.