From: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/3] Generalized "string function" syntax
Date: Tue, 20 Oct 2009 01:07:03 +0200 [thread overview]
Message-ID: <4ADCF117.2030905@lsrfire.ath.cx> (raw)
In-Reply-To: <7vr5t0nwu8.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> 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.
> 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().
> 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é
next prev parent reply other threads:[~2009-10-19 23:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-16 8:28 [PATCH 0/3] Generalized "string function" syntax Junio C Hamano
2009-10-16 8:28 ` [PATCH 1/3] format_commit_message(): fix function signature Junio C Hamano
2009-10-17 21:04 ` René Scharfe
2009-10-16 8:28 ` [PATCH 2/3] strbuf_nested_expand(): allow expansion to interrupt in the middle Junio C Hamano
2009-10-16 11:30 ` Johannes Schindelin
2009-10-16 17:22 ` Junio C Hamano
2009-10-16 8:28 ` [PATCH 3/3] Add proof-of-concept %[w(width,in1,in2)<<any-string>>%] implementation Junio C Hamano
2009-10-16 11:32 ` Johannes Schindelin
2009-10-16 17:25 ` Junio C Hamano
2009-10-16 18:02 ` Jakub Narebski
2009-10-16 19:01 ` Junio C Hamano
2009-10-16 22:19 ` Jakub Narebski
2009-10-16 23:23 ` Junio C Hamano
2009-10-17 0:00 ` Jakub Narebski
2009-10-17 0:18 ` Junio C Hamano
2009-10-17 21:04 ` [PATCH 0/3] Generalized "string function" syntax René Scharfe
2009-10-18 4:18 ` Junio C Hamano
2009-10-18 8:24 ` René Scharfe
2009-10-18 22:47 ` Junio C Hamano
2009-10-19 23:07 ` René Scharfe [this message]
2009-10-19 23:18 ` Junio C Hamano
2009-11-08 1:02 ` René Scharfe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ADCF117.2030905@lsrfire.ath.cx \
--to=rene.scharfe@lsrfire.ath.cx \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).