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

[Matt Mackall]

On Fri, 2012-12-21 at 12:29 -0600, Sean Farley 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.

(templating)

> 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)?

We might for instance show a user in one style in one place (ie log),
but in another style elsewhere (annotate?). So this sort of thing:

-    return ctx.user()
+    return labelify(ctx.user(), 'log.user')

..hardcodes knowledge of 'log' in a place it shouldn't exist.

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

Well it's the first I've heard of it at any rate.

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

Ok, but you can probably agree that a) it's nice and shiny for template
users to be able to specify colors directly and b) it's really easy.

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

It's a no-op in that it just returns the input string, but then color
has a convenient function to wrap to do its magic.

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

Well if you want to send 'decorated' data through this pipeline from its
origin, there are pretty much only two options:

a) out-of-band, like you're suggesting
b) in-band, via escape sequences

The downside of (a) is that it's complicated and slow due to needing to
emulate a "string" as a bunch of data/metadata fragments. I don't think
it's a valuable enough feature to justify that.

On the other hand, (b) is problematic because it potentially fouls up
filters. My proposal is:

c) add in-band escaping away from the origin

It's not perfect, but its utility-to-complexity ratio is quite
favorable.

-- 
Mathematics is the supreme nostalgia of our time.