[PATCH 1 of 2 STABLE] templater: do not process \-escapes at parsestring() (issue4290)

Yuya Nishihara yuya at tcha.org
Fri May 8 00:34:35 CDT 2015


On Thu, 07 May 2015 17:49:49 -0700, Sean Farley wrote:
> Yuya Nishihara <yuya at tcha.org> writes:
> > # HG changeset patch
> > # User Yuya Nishihara <yuya at tcha.org>
> > # Date 1430700841 -32400
> > #      Mon May 04 09:54:01 2015 +0900
> > # Branch stable
> > # Node ID 888d7a553f2b0ace8563ea9e3ef3ab1b8a50923e
> > # Parent  a4ee6f774f14b68e8dc887745699ba6a2ae28355
> > templater: do not process \-escapes at parsestring() (issue4290)
> >
> > This patch brings back pre-2.8.1 behavior.
> >
> > The result of parsestring() is stored in templater's cache, t.cache, and then
> > it is parsed as a template string by compiletemplate(). So t.cache should keep
> > an unparsed string no matter if it is sourced from config value. Otherwise
> > backslashes would be processed twice.
> >
> > The test vector is borrowed from 64b4f0cd7336.
> 
> So, this breaks the following template for me:
> 
> $ cat ~/sandbox/.hgrc
> [templates]
> sl = "{tags % \"{ifeq(tag,'tip','',label('log.tag', ' {tag}'))}\"}"
> 
> $ HGRCPATH=~/sandbox/.hgrc lhg log -G -T sl -r 3.4-rc
> obsolete feature not enabled but 68581 markers found!
> hg: parse error at 8: syntax error

Perhaps we have to strip '\"' before parsing template?

If I understand it, '"' is the magic character to embed template strings
in map files. '\"' isn't necessary [1], but it looks like a correct syntax if
surrounded by '"'s.

 [1]: http://selenic.com/repo/hg/file/17ba4ccd20b4/mercurial/templates/paper/map#l75

--- a/mercurial/templater.py
+++ b/mercurial/templater.py
@@ -623,7 +623,7 @@ def parsestring(s, quoted=True):
     if quoted:
         if len(s) < 2 or s[0] != s[-1]:
             raise SyntaxError(_('unmatched quotes'))
-        return s[1:-1]
+        return s[1:-1].replace('\\%s' % s[0], s[0])
 
     return s
 

> Matt's original 64b4f0cd7336 changeset was written side-by-side with me
> at a coffee shop in NYC. It seems there is still a corner case with
> issue4102 that I'm hitting.


More information about the Mercurial-devel mailing list