[PATCH v2] templater: add separate() template function

Martin von Zweigbergk martinvonz at google.com
Wed May 4 23:19:35 EDT 2016


Perhaps we can extend join() after all. When given at least 3 arguments,
the last one can still be the separator and the ones before it are the
items to separate. It's a little weird to have the separator last, but it
does avoid the need for a new name. Thoughts?

On Wed, May 4, 2016, 16:52 Sean Farley <sean at farley.io> wrote:

>
> Martin von Zweigbergk via Mercurial-devel <
> mercurial-devel at mercurial-scm.org> writes:
>
> > On Wed, May 4, 2016 at 5:06 AM, Yuya Nishihara <yuya at tcha.org> wrote:
> >> On Tue, 03 May 2016 21:45:17 -0700, Martin von Zweigbergk via
> Mercurial-devel wrote:
> >>> # HG changeset patch
> >>> # User Martin von Zweigbergk <martinvonz at google.com>
> >>> # Date 1462294194 25200
> >>> #      Tue May 03 09:49:54 2016 -0700
> >>> # Node ID 9be8673e90a26c27276b8c8963b86b95a8f184e6
> >>> # Parent  8eba4cdcfd810d80785c94d770a442c5bd1f9d0f
> >>> templater: add separate() template function
> >>>
> >>> 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() takes the separator first in order to allow a variable
> >>>    number of arguments after it
> >>>
> >>>  * separate() skips empty arguments
> >>>
> >>>  * join() expects a single list argument, while separate() accepts
> >>>    either a single list or separate arguments
> >>>
> >>> diff -r 8eba4cdcfd81 -r 9be8673e90a2 mercurial/help/templates.txt
> >>> --- a/mercurial/help/templates.txt    Sun Apr 17 12:31:06 2016 +0900
> >>> +++ b/mercurial/help/templates.txt    Tue May 03 09:49:54 2016 -0700
> >>> @@ -81,6 +81,10 @@
> >>>
> >>>     $ hg log -r 0 --template "files: {join(files, ', ')}\n"
> >>>
> >>> +- Separate non-empty arguments by a " "::
> >>> +
> >>> +   $ hg log -r 0 --template "{separate(' ', node, bookmarks, tags}\n"
> >>> +
> >>>  - Modify each line of a commit description::
> >>>
> >>>     $ hg log --template "{splitlines(desc) % '**** {line}\n'}"
> >>> diff -r 8eba4cdcfd81 -r 9be8673e90a2 mercurial/templater.py
> >>> --- a/mercurial/templater.py  Sun Apr 17 12:31:06 2016 +0900
> >>> +++ b/mercurial/templater.py  Tue May 03 09:49:54 2016 -0700
> >>> @@ -621,6 +621,28 @@
> >>>              yield joiner
> >>>          yield x
> >>>
> >>> + at templatefunc('separate(sep, args)')
> >>> +def separate(context, mapping, args):
> >>> +    """Add a separator between non-empty arguments."""
> >>> +    if not args:
> >>> +        # i18n: "separate" is a keyword
> >>> +        raise error.ParseError(_("separate expects at least one
> argument"))
> >>> +
> >>> +    sep = evalstring(context, mapping, args[0])
> >>> +    things = [evalfuncarg(context, mapping, arg) for arg in args[1:]]
> >>> +    if len(things) == 1 and util.safehasattr(things[0], 'values'):
> >>> +        things = things[0].values
> >>
> >> Perhaps we can assume things[0] a list if len(args[1:]) == 1.
> >> separate(' ', nonlist) is useless just like built-in min(x) function.
> >
> > I considered that. I don't know which is less surprising, having
> > behavior depending on number of arguments or type of arguments (and
> > number of them). I could go either way. Any votes in either direction?
>
> At first glance, I'd rather have 'join' become smarter (and it seems
> more elegant).
>
> > Btw:
> >
> > $ hg log -T '{join(1)}'
> > [stack trace]
> > TypeError: 'int' object is not iterable
> >
> > Stupid use case, but we should eliminate the stack trace.
>
> Ah, nice catch. I'll leave it to Yuya, hehe.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160505/76f11238/attachment.html>


More information about the Mercurial-devel mailing list