Before, _hybrid.gen must be a generator which could be consumed only once.
It was okay in templatekw.py since template keywords are functions which
create temporary hybrid objects, but the formatter doesn't work in that way.
To work around the issue, this patch makes _hybrid.gen optionally be a
function returning a generator.
Thanks to Pulkit for finding this issue.
Otherwise nested template formatter would not see the context objects.
It's just a boolean flag now. We might want to change it to 'ctxs -> items'
function so changectx attributes are populated automatically in JSON, but
I'm not sure.
Unlike a mapfile whose template is looked up by spec -> mapfile -> topic,
[templates] section is global. We use :sub-section syntax to define parts
per template.
Now spec.ref should be '' if spec.tmpl is specified. Since spec.ref is the
option to select the initial template to be rendered, it doesn't make sense
to store the given literal template as spec.ref.
Since a map file has another level to select a template (spec -> mapfile
-> topic), this isn't exactly the same as how a map file works. But I believe
most users would expect the new behavior.
A literal template is stored as an unnamed template so that it will never
conflict with the templates defined in [templates] section.
This provides a simpler API for callers which don't need full templating
stack. Instead of storing the given template as the name specified by topic,
use '' as the default template to be rendered.
This will allow us to change the initial template reference depending on how
the template is looked up. For example,
-Tdefault => (ref='changeset', tmpl=None, mapfile='map-cmdline.default')
-T'{rev}' => (ref='', tmpl='{rev}', mapfile=None)
A literal template given by -T option will be stored as an unnamed template,
which will free up the template namespace so that we can load named templates
from [templates] section of user config.
I'm going to add more options to the templatespec tuple.
cmdutil.logtemplatespec() is just an alias now, but it will be changed to
a factory function later.
Since it's highly use-case dependent how template should be looked up,
gettemplater() function isn't useful. Keeping it would introduce another
bug I've made and fixed earlier in this series.
I believe it was a mistake to open file in text mode. Now '\r' is preserved
on Windows, but it should be okay to print '\r\n' as long as users live in
such platform.
To make things simple, openformatter() and maybereopen() have no support
for a plain object API. Callers must use the "with" statement.
Unlike cmdutil.makefileobj(), append mode ('ab') isn't supported by these
functions. This is because JSON output can't be simply concatenated. Perhaps
cmdutil.export() will have to build a {filename: [revs...]} map first and
write revs per file.
This was originally written for JSON templating where we would have to be
careful to not add extra comma, but seems generally useful.
Inner loop started by % operator has its own counter.
By luck, we appear to not pass any long instances into
the JSON formatter. I suspect this will change with all the
Python 3 porting work. Plus I have another series that will
convert some ints to longs that triggers this.
The _first field is used for tracking when to emit a separator between
items. It seems like it's clearly formatter state, not ui state, so
let's move it there.
This allows us to build data not written to the console. That would be
doable by ui.pushbuffer()/popbuffer(), but changing the file object seems
cleaner.
Some formatter-based commands provide fields that are identical to the ones
defined in templatekw, but we had to specify them manually to support all
changeset-based template keywords.
This patch adds fm.context() that populates all templatekw. These keywords
are available only in template output, so we still need to set important
keywords via fm.data() if they should be available in e.g. JSON output.
Currently fm.context() takes only 'ctx' argument. It will eventually be
extended to take 'fctx' to support file-based keywords (e.g. {path}) seen
in hgweb.
And port "hg files" to test it.
As you can see, extra indent is necessary to port to this API. I don't think
we should switch every fm.formatter() call to "with" statement.
We sometimes need to build nested items by formatter, but there was no
convenient way other than building and putting them manually by fm.data():
exts = []
for n, v in extensions:
fm.plain('%s %s\n' % (n, v))
exts.append({'name': n, 'ver': v})
fm.data(extensions=exts)
This should work for simple cases, but doing this would make it harder to
change the underlying data type for better templating support.
So this patch provides fm.nested(field), which returns new nested formatter
(or self if items aren't structured and just written to ui.) A nested formatter
stores items which will later be rendered by the parent formatter.
fn = fm.nested('extensions')
for n, v in extensions:
fn.startitem()
fn.write('name ver', '%s %s\n', n, v)
fn.end()
Nested items are directly exported to a template for now:
{extensions % "{name} {ver}\n"}
There's no {extensions} nor {join(extensions, sep)} yet. I have a plan for
them by extending fm.nested() API, but I want to revisit it after trying
out this API in the real world.
New converter classes will be reused by a nested formatter. See the next
patch for details.
This change is also good in that the default values are defined uniquely
by the baseformatter.
This will be used to process key-value pairs by formatter. The default
field names and format are derived from the {extras} template keyword.
Tests will be added later.
Before, it wasn't possible for formatter to handle array structure other
than date tuple. We've discussed that at the last sprint, which ended we
would probably want to allow only templatable data structure, i.e. a list
of dicts:
data(tags=[{'tag': a}, {'tag': b}, ...])
Unfortunately, it turned out not working well with template functions:
"{ifcontains(a, tags, ...)}"
^^^^^^^^^^^^^^^^^^
"a in tags", where tags should be a plain list/set of tags
So the formatter must at least know if the type [{}] was constructed from
a plain list or was actually a list of dicts.
This patch introduces new explicit interface to convert an array structure
to an appropriate data type for the current formatter, which can be used
as follows:
fm.write('tags', _('tags: %s\n'), fm.formatlist(tags, name='tag'))
No separate fm.data() call should be necessary.
The cPickle is renamed to _pickle in python3 and this C extension is available
in pickle which was not included in earlier versions. So imports are conditionalized
to import cPickle in py2 and pickle in py3. Moreover the use of pickle in py2 is
switched to cPickle as the C extension is faster. The hack is added in util.py and
the modules import util.pickle
Now template aliases are fully supported in log and formatter templates.
As I said before, aliases are not expanded in map files. This avoids possible
corruption of our stock styles and web templates. This behavior is undocumented
since no map file nor [templates] section are documented at all. Later on,
we might want to add [aliases] section to map files if it appears to be useful.
This function will host loading of template aliases. It is not defined at
templater, but at formatter, since formatter is the module handling ui stuff
in front of templater.
New frommapfile() function will make it clear when template aliases will be
loaded. They should be applied to command arguments and templates in hgrc,
but not to map files. Otherwise, our stock styles and web templates
(i.e map-file templates) could be modified unintentionally.
Future patches will add "aliases" argument to __init__(), but not to
frommapfile().
