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

[Simon King]

On 21 Dec 2012, at 18:29, Sean Farley <sean.michael.farley at gmail.com> wrote:

> 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.
>

I've not really looked at the templater code, or the GenericTemplating
proposal, so this may not make any sense at all, but could it be done
with a subclass of str ("taggedstring") that carries the tag with it,
but is otherwise transparent to the rest of the system?

Simon