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

[Martin von Zweigbergk]

I'll send a V3 with no special treatment of lists. That seems safest
to me. We can add support for lists before the next release, or after
if we can accept the minor BC breakage.

On Thu, May 5, 2016 at 7:23 AM, Martin von Zweigbergk
<martinvonz at google.com> wrote:
> Sorry, s/do support/drop support/
>
>
> On Thu, May 5, 2016, 07:22 Martin von Zweigbergk <martinvonz at google.com>
> wrote:
>>
>> I'm tempted to just do support for list arguments and let the user use
>> join() for those. What do others think? Matt?
>>
>> On Thu, May 5, 2016, 00:24 Yuya Nishihara <yuya at tcha.org> wrote:
>>>
>>> On Thu, 05 May 2016 04:36:14 +0000, Martin von Zweigbergk wrote:
>>> > On Wed, May 4, 2016 at 8:51 PM Yuya Nishihara <yuya at tcha.org> wrote:
>>> > > On Thu, 05 May 2016 03:19:35 +0000, Martin von Zweigbergk wrote:
>>> > > > 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?
>>> > >
>>> > > or introduce a list constructor?
>>> > >
>>> > >   join(items(node, bookmarks, tags), " ")
>>> > >   items(node, bookmarks, tags) % "{item} "
>>> > >
>>> > > No idea if it should implicitly drop empty items.
>>> >
>>> > Right, I just remembered that point too. So a new function is probably
>>> > best.
>>> >
>>> > So the difference between your proposal and Matt's is when two
>>> > arguments
>>> > are given and the second one is not a list, for example:
>>> >
>>> > separate(" ", rev)
>>> > separate(" ", branch)
>>> >
>>> > With Matt's proposal, they would be allowed (and pointless) and with
>>> > your
>>> > proposal they would be disallowed. Although pointless, I think it's a
>>> > small
>>> > win that separate(" ", rev, branch) can be simplified into one of the
>>> > above
>>> > and still work without forcing the user to clean it up by dropping the
>>> > call
>>> > to separate. Perhaps the user has a group of similar calls and wants to
>>> > keep the separate() for consistency.
>>> >
>>> > Also note that, with either proposal, these two behave quite
>>> > differently:
>>> >
>>> > separate(":", node, branches)
>>> > separate(":", branches)
>>>
>>> Yeah, that's one reason I insist that separate(":", rev) should be
>>> disallowed.
>>> If both separate(":", rev) and separate(":", branches) are allowed, I
>>> would
>>> expect that separate() is the function to flatten lists.
>>>
>>>   separate(":", rev)             # {rev}
>>>   separate(":", branches)        # {branch0}:{branch1}
>>>   separate(":", branches, tags)  # {branch0}:{branch1}:{tag0}:{tag1}