From: Junio C Hamano <gitster@pobox.com>
Date: Sun, 18 Oct 2009 22:47:27 GMT
Subject: Re: [PATCH 0/3] Generalized "string function" syntax
Message-ID: <7vr5t0nwu8.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4ADAD0D2.504@lsrfire.ath.cx>

René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:

> Which other text functions are we going to add which would break this
> model?  The only thing I can think of right now is nesting such
> functions themselves, e.g. when indenting a list in an indented
> sub-paragraph in an indented paragraph.  Useful?

I was more worried about painting ourselves now in a corner we cannot get
out of easily later.  Even if my answer to question "what are we going to
add" may be "nothing I can think of right now", it does not make me happy.

Something off the top of my head are combinations like these.

    %[toupper()%cD%] => 'SUN, 18 OCT 2009 12:34:56 -0700'
    %[substr(7,3)%[toupper()%cD%]] => 'OCT'

    %[sanitize()%s%] === %f (i.e. format-patch filename)
    %[sanitize()%[substr(0,7)%[toupper()%aN%]%]%s] (with upcased author name)

By the way, I think that date formatting can be helped by introducing a
strftime() function that takes %ct/%at as input, e.g. %aD would become

    %[strftime(%a, %d %b %Y %H:%M:%S %z)%at]

and we do not have to worry about keep adding random %[ac]X formats and
running out of X.  Right now we use d/D/r/i and there were talks of adding
a shortened 8601 format without time or something we did not implement.

Also, if we had this %[func() any string%] mechanism, we probably wouldn't
have had to add distinction between n/N and e/E after %a and %c.