[PATCH 00 of 10 RFC] adding labels to the template engine

[Sean Farley]

On Fri, Dec 21, 2012 at 1:43 AM, Matt Mackall <mpm at selenic.com> wrote:
> On Thu, 2012-12-20 at 23:37 -0600, Sean Farley wrote:
>> I'm looking for some feedback for my attempt at adding label data to
>> the template engine. I had some questions arise while I was working on
>> this patch series and before sending the whole thing to the list, I
>> thought I would send some preliminary work with questions in the
>> comments of the code and/ or the commit message.
>
> I had to read quite a ways into this series to figure out what the point
> of this was, which is apparently: add color support to command-line
> templates.

My apologies. I guess I was trying to convey too much. I was thinking
this could be eventually used with your GenericTemplating but maybe
not after reading your response.

> For one thing, I think this will run afoul of the infrastructure that
> I've been working on for GenericTemplating.

Hmm, yes, it changes a dictionary of strings to a dictionary of dictionaries :-/

> For another, we're going to
> have contexts other than 'log' in tempting.

Righto, I haven't sent the entire patch series, just this snippet so I
can get some feedback. I believe you're referring to eventually using
templates for internal commands everywhere instead of having two ways
of outputting (i.e. ui.write vs. templater engine)?

> Lastly, it complexifies
> the templater quite a bit for a feature I have only seen one person
> express interest in.

Aw man, come on now. It's been at least three people!

> It might instead be better for color.py to extend the template functions
> so that people writing templates can do something like:
>
>  {color('log.user', user)}
>
> or even
>
>  {color('blue', user)}
>
> that simply adds in the relevant escape codes to the provided string
> when using a tty and ends up being very simple to write.

Yes, I experimented with this version but didn't like the fact that a
user had to manually add it to the template.

> Alternately, we can have a no-op predicate like label() that color.py
> overrides:
>
>  {label('log.user', user)}

I tried this as well but ran into a problem with the no-op part. To
preserve the labeling information, I had to wrap it in some way
because there could be things like,

{label('log.changeset changeset.%s', node)}

where 'changeset.%s' should be replaced with node.phasestr(). The same
happens with trying to label file status (i.e. {label('status.%s',
files)}). Even if the function that generates the data (let's say
{node}) generated the label information in the form
{label('log.changeset changeset.secret',
c9cdf41cf6a0124436b32db24bff14b901f4a852} then there would be a
problem running it through any filters.

So, basically, I'm trying to tag the information far down in the chain
and keep it untouched somehow as it bubbles up the template machinery.
I would like to hear if anyone has a better idea than what I described
above.