A pretty common pattern in templates is adding conditional separators
like so:
{node}{if(bookmarks, " {bookmarks}")}{if(tags, " {tags}")}
With this patch, the above can be simplified to:
{separate(" ", node, bookmarks, tags)}
The function is similar to the already existing join(), but with a few
differences:
* separate() skips empty arguments
* join() expects a single list argument, while separate() expects
each item as a separate argument
* separate() takes the separator first in order to allow a variable
number of arguments after it
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.
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().
The debugtemplate command is updated to show expanded tree, but still the
template engine doesn't support alias expansion. That's why the test says
"parse error" for now.
This will be a parser of template aliases, and it can also be used for
processing quoted string templates in map files. That's why this function
isn't defined in the upcoming _aliasrules class.
Before, KeyError was caught at changeset_templater._show(), which said "no
key named '%s'" as it was intended to catch the KeyError of unknown map key.
Instead, we should catch KeyError explicitly for better error indication.
For those who don't know what the template engine is (read "everyone"), it is
hidden extension feature that allows switching template syntax in map file.
See b901d7e82888 for details.
Using decorator can localize changes for adding (or removing) a
template function in source code.
This patch also removes leading ":FUNC(ARG...):" part in help document
of each function, because using templatefunc makes it useless.
This patch uses not 'func' but 'templatefunc' as a decorator name,
because the former is too generic one, even though the latter is a
little redundant in 'templater.py'.
This patch also adds loadfunction() to templater, because this
combination helps to figure out how they cooperate with each other.
Listing up loadfunction() in dispatch.extraloaders causes implicit
loading template function at loading (3rd party) extension.
This patch explicitly tests whether templatefunc decorator works as
expected, because there is no bundled extension, which defines
template function.
This change requires that "templatefunc" attribute of (3rd party)
extension is registrar.templatefunc or so.
Before this patch, the first and last characters were stripped from
ui.logtemplate and template.* if they were the same. It could lead to a
strange result as quotes are optional. See the test for example.
SyntaxError is the class representing syntax errors in Python code. We should
use a dedicated exception class for our needs. With this change, unnecessary
re-wrapping of SyntaxError can be eliminated.
This patch eliminates a nested data structure other than the parsed tree.
('template', [(op, data), ..]) -> ('template', (op, data), ..)
New expanded tree can be processed by common parser functions. This change
will help implementing template aliases.
Because a (template ..) node should have at least one child node, an empty
template (template []) is mapped to (string ''). Also a trivial string
(template [(string ..)]) node is unwrapped to (string ..) at parsing phase,
instead of compiling phase.
Now compiled template fragments are packed into a generic type, (func, data),
a string can be a valid template. This change allows us to unwrap a trivial
string node. See the next patch for details.
Before this patch, parsed and compiled templates were kept as lists. That
was inconvenient for applying transformation such as alias expansion.
This patch changes the types of the outermost objects as follows:
stage old new
-------- -------------- ------------------------------
parsed [(op, ..)] ('template', [(op, ..)])
compiled [(func, data)] (runtemplate, [(func, data)])
New templater.parse() function has the same signature as revset.parse()
and fileset.parse().
Silent failure hides bugs and makes it harder to track down the issue. It's
worse than raising exception.
In future patches, I plan to sort out template functions that require 'ui',
'ctx', 'fctx', etc. so that incompatible functions are excluded and the doc can
say in which context these functions are usable.
@templatefunc('label', requires=('ui',))
def label(context, mapping, args):
...
If your mercurial/templates/ directory is dirty, then the template system would
otherwise import duplicate templates from the .orig files and potentially try to
parse .rej files.
Since editing/reverting these templates isn't an unexpected action, and since
they're in .hgignore, it's best that the template system know to skip them."
To describe the bug this fix is addressing, one can do
``$ hg status -T "{label('red', path)}\n" --color=debug``
and observe that the label is not applied before my fix and applied with it.
Instead of the mapping hack introduced by d4686e0c15c9, this patch changes the
way how a label symbol is evaluated. This is still hackish, but should be more
predictable in that it doesn't depend on the known color effects.
This change is intended to eliminate the reference to color._effects so that
color.templatelabel() can be merged with templater.label().
Before this, "{noniterable % template}" raised an exception. This tries to
provide a better indication for the common case, where a left-hand-side
expression is a keyword.
A function argument may be an integer. In this case, it isn't necessary to
convert a value to string and back to integer.
Because an argument may be an arbitrary object (e.g. date tuple), TypeError
should be caught as well.
If a key is constructed from a template expression, it may be a generator.
In that case, a key have to be stringified.
A dictarg should never be a generator, but this patch also changes it to
call evalfuncarg() for consistency.
High-level use case: printing a list of objects with formatter
when each object in turn contains a list of properties (like
when % template symbol is used in {things % '{thing}'}
Let the top-level list contain one thing with two properties:
objs = [{
'props': [
{ 'value': 1, 'show': 1 },
{ 'value': 2 }]
}]
(please note that second property does not have 'show' key)
If a templateformatter is used to print this with template
"{props % '{if(show, value)}'}"
current implementation will print value for both properties,
which is a bug. This happens because in `templater.runmap`
function we only rewrite mapping values with existing new
values for each item. If some mapping value is missing in
the item, it will not be removed.
In this case, a template is parsed recursively with no thunk for lazy
evaluation. This patch prevents recursion by putting a dummy of the same name
into a cache that will be referenced while parsing if there's a recursion.
changeset = {files % changeset}\n
~~~~~~~~~
= [(_runrecursivesymbol, 'changeset')]
It would be nice if we could detect recursion at the parsing phase, but we
can't because a template can refer to a keyword of the same name. For example,
"rev = {rev}" is valid if rev is a keyword, and we don't know if rev is a
keyword or a template while parsing.
This is necessary to obtain a _hybrid object from a dict. If get() yields
a value, it would be stringified.
I see no benefit to make get() lazy, so this patch just changes "yield" to
"return".
In templater, a callable symbol exists for lazy evaluation, which should have
f(**mapping) signature. On the other hand, _hybrid.__call__(), which was
introduced by 4e182fb53989, generates mapping for each element.
This patch renames _hybrid.__call__() to _hybrid.itermaps() so that a _hybrid
object can be a value of a mapping dict.
{namespaces % "{namespace}: {names % "{name }"}\n"}
~~~~~
a _hybrid object
The home of 'Abort' is 'error' not 'util' however, a lot of code seems to be
confused about that and gives all the credit to 'util' instead of the
hardworking 'error'. In a spirit of equity, we break the cycle of injustice and
give back to 'error' the respect it deserves. And screw that 'util' poser.
For great justice.
It was introduced by 236440938a03, but the important code was removed by
fcf2407610f4. So there was no positive effect other than exhausting memory.
The problem spotted by 236440938a03 is that you can't use a generator keyword
more than once. For example, in hgweb template, "{child} {child}" doesn't work
because the first "{child}" consumes the generator. But as fcf2407610f4 says,
the fix was wrong because it could overwrite a callable keyword that returns
a generator. Also the fix didn't work for a generator of generator such as
"{diff}" keyword. So, the proper fix for that problem would be to not put
a generator in a keyword table. Instead, it should be a factory of a generator.
Note that this should fix the memory issue in hgweb, but my firefox killed by
OOM in place. Be careful to not use a modern web browser to test the issue4868.
This allows the latest class of tag to be found, such as a release candidate or
final build, instead of just the absolute latest.
It doesn't appear that the existing keyword can be given an optional argument.
There is a keyword, function and filter for 'date', so it doesn't seem harmful
to introduce a new function with the same name as an existing keyword. Most
functions are pretty Mercurial agnostic, but there is {revset()} as precedent.
Even though templatekw.getlatesttags() returns a single tuple, one entry of
which is a list, it is simplest to present this as a list of tags instead of a
single item, with each tag having a distance and change count attribute. It is
also closer to how {latesttag} returns a list of tags, and how this function
works when not given a '%' operator.
