Re: [PATCH 0/3] Generalized "string function" syntax

From: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Date: Oct 19, 2009, 23:07 UTC
Message-ID: <4ADCF117.2030905@lsrfire.ath.cx>
In-Reply-To: <7vr5t0nwu8.fsf@alter.siamese.dyndns.org>

Junio C Hamano schrieb:

Show 10 quoted lines

> 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.

If wrapping wasn't implemented as a nested function, nesting could still be introduced independently and used for other things -- once these other things arrive.

Show 7 quoted lines

> 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)

Interesting examples, I particular like sanitize().

Show 8 quoted lines

> 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.

The number of date formats is scary, but this could be solved e.g. by introducing "%aT(<date format specifiers etc.>)", without nesting.

> 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.

Yeah, the place holders multiplied, and some of that growth could have been avoided by providing ways to change the change the output instead of providing the processed results.

However, I think that nesting is such a big addition that it warrants further planning. It turns the simple "see place holder, fill in value" interpolator into more of a programming language. Is that really needed? And if yes, do we want to keep all these percent signs around or is it better to invent a nicer syntax? Or borrow it from somewhere else? Or perhaps I'm just afraid of change and complexity.

Anyway, all of the functions that accept strings need to be able to skip over escape codes, which includes all of those mentioned above except perhaps strftime. This is ugly. Or one could forbid colour codes in function arguments.

I'm more in favour of adding ways to customize the shape of the elements rather than adding string functions. %S(width=76,indent=4) over %[wrap(76,4)%s%].

I feel I need to think a bit more about this; currently I'm a bit scared by %[...%]. But first to catch some sleep..

René