Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:20:24 -0400] rev 20682
minirst: move from dict() construction to {} literals
The latter are both faster and more consistent across Python 2 and 3.
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:20:04 -0400] rev 20681
webutil: move from dict() construction to {} literals
The latter are both faster and more consistent across Python 2 and 3.
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:19:43 -0400] rev 20680
run-tests: move from dict() construction to {} literals
The latter are both faster and more consistent across Python 2 and 3.
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:19:20 -0400] rev 20679
util: move from dict() construction to {} literals
The latter are both faster and more consistent across Python 2 and 3.
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:29:07 -0400] rev 20678
webcommands: move from dict() construction to {} literals
The latter are both faster and more consistent across Python 2 and 3.
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:15:37 -0400] rev 20677
hgwebdir_mod: move from dict() construction to {} literals
The latter are both faster and more consistent across Python 2 and 3.
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:15:09 -0400] rev 20676
filemerge: move from dict() construction to {} literals
The latter are both faster and more consistent across Python 2 and 3.
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:14:31 -0400] rev 20675
changegroup: move from dict() construction to {} literals
The latter are both faster and more consistent across Python 2 and 3.
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:13:42 -0400] rev 20674
extdiff: move from dict() construction to {} literals
The latter are both faster and more consistent across Python 2 and 3.
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:13:10 -0400] rev 20673
bugzilla: move from dict() construction to {} literals
The latter are both faster and more consistent across Python 2 and 3.
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:12:26 -0400] rev 20672
synthrepo: move from dict() construction to {} literals
The latter are both faster and more consistent across Python 2 and 3.
Augie Fackler <raf@durin42.com> [Wed, 12 Mar 2014 13:00:51 -0400] rev 20671
wireproto: remove todict() and use {} literals instead
Matt Mackall <mpm@selenic.com> [Tue, 11 Mar 2014 16:19:08 -0500] rev 20670
merge with stable
Matt Mackall <mpm@selenic.com> [Mon, 10 Mar 2014 15:00:41 -0500] rev 20669
templater: deprecate --style now that -T exists
Matt Mackall <mpm@selenic.com> [Sat, 08 Mar 2014 17:38:50 -0600] rev 20668
templating: make -T much more flexible
It can now accept styles and paths and references to settings in
[templates].
Matt Mackall <mpm@selenic.com> [Sat, 08 Mar 2014 16:14:08 -0600] rev 20667
changeset_templater: remove use_template method
Matt Mackall <mpm@selenic.com> [Sat, 08 Mar 2014 16:01:58 -0600] rev 20666
cmdutil: make helper function to process template args
Matt Mackall <mpm@selenic.com> [Sat, 08 Mar 2014 15:27:25 -0600] rev 20665
commands: add -T alternative to --template
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 07 Mar 2014 14:29:26 -0500] rev 20664
config: clarify and exemplify the user name in the sample config file
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 10 Mar 2014 01:01:43 +0900] rev 20663
templater: make strings in template expressions be "string-escape"-ed correctly
Changeset
64b4f0cd7336 (released with 2.8.1) fixed "recursively
evaluate string literals as templates" problem (
issue4102) by moving
the location of "string-escape"-ing from "tokenizer()" to
"compiletemplate()".
But some parts in template expressions below are not processed by
"compiletemplate()", and it may cause unexpected result.
- 'expr' of 'if(expr, then, else)'
- 'expr's of 'ifeq(expr, expr, then, else)'
- 'sep' of 'join(list, sep)'
- 'text' and 'style' of 'rstdoc(text, style)'
- 'text' and 'chars' of 'strip(text, chars)'
- 'pat' and 'repl' of 'sub(pat, repl, expr)'
For example, '\n' of "{join(extras, '\n')}" is not "string-escape"-ed
and treated as a literal '\n'. This breaks "Display the contents of
the 'extra' field, one per line" example in "hg help templates".
Just "string-escape"-ing on each parts above may not work correctly,
because inside expression of nested ones already applies
"string-escape" on string literals. For example:
- "{join(files, '\n')}" doesn't return "string-escape"-ed string, but
- "{join(files, if(branch, '\n', '\n'))}" does
To fix this problem, this patch does:
- introduce "rawstring" token and "runrawstring" method to handle
strings not to be "string-escape"-ed correctly, and
- make "runstring" method return "string-escape"-ed string, and
delay "string-escape"-ing until evaluation
This patch invokes "compiletemplate()" with "strtoken=exp[0]" in
"gettemplate()", because "exp[1]" is not yet evaluated. This code path
is tested via mapping ("expr % '{template}'").
In the other hand, this patch invokes it with "strtoken='rawstring'"
in "_evalifliteral()", because "t" is the result of "arg" evaluation
and it should be "string-escape"-ed if "arg" is "string" expression.
This patch doesn't test "string-escape"-ing on 'expr' of 'if(expr,
then, else)', because it doesn't affect the result.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 10 Mar 2014 01:01:43 +0900] rev 20662
templater: apply "stringify()" on sub expression to get string correctly
Templating syntax allows nested expression to be specified as parts
below, but they are evaluated as a generator and don't work correctly.
- 'sep' of 'join(list, sep)'
- 'text' and 'chars' of 'strip(text, chars)'
In the former case, 'sep' returns expected string only for the first
separation, and empty one for the second or later, because the
generator has only one element.
In the latter case, templating is aborted by exception, because the
generator doesn't have 'strip()' method (as 'text') and can't be
passed as the argument to 'str.strip()' (as 'chars').
This patch applies "stringify()" on these sub expression to get string
correctly.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 10 Mar 2014 01:01:42 +0900] rev 20661
templater: avoid recursive evaluation of string literals completely
Changeset
3d8bfe2ecf6d (released with 2.8.1) fixed "recursively
evaluate string literals as templates" problem (
issue4103) by
introducing "_evalifliteral()".
But some parts in template expressions below are still processed by
the combination of "compiletemplate()" and "runtemplate()", and may
cause same problem unexpectedly.
- 'init' and 'hang' of 'fill(text, width, init, hang)'
- 'expr' of 'sub(pat, repl, expr)'
- 'label' of 'label(label, expr)'
This patch processes them by "_evalifliteral()" instead of the
combination of "compiletemplate()" and "runtemplate()" to avoid
recursive evaluation of string literals completely.
Matt Mackall <mpm@selenic.com> [Thu, 06 Mar 2014 17:26:49 -0600] rev 20660
status: improve explanation of ' ' status
a) it shows for states other than 'A'
b) it only shows with --copies
Lucas Moscovicz <lmoscovicz@fb.com> [Tue, 18 Feb 2014 13:07:08 -0800] rev 20659
revset: changed methods in spanset to return ordered sets
Now __sub__ and __and__ can smartly return ordered lazysets.