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: Sun, 18 Oct 2009 10:24:50 +0200 [thread overview]
Message-ID: <4ADAD0D2.504@lsrfire.ath.cx> (raw)
In-Reply-To: <7v63ad5o8p.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> Junio C Hamano schrieb:
>>> I mentioned an idea to enhance the pretty=format language with a
>>> string function syntax that people can extend by adding new functions
>>> in one of the "What's cooking" messages earlier. The general syntax
>>> would be like
>>>
>>> %[function(args...)any string here%]
>>>
>>> where "any string here" part would have the usual pretty=format
>>> strings. E.g. git show -s --format='%{w(72,8,4)%s%+b%]' should give
>>> you a line wrapped commit log message if w(width,in1,in2) is such a
>>> function.
>> I pondered line wrapping with format strings briefly a long time ago, and
>> I always considered it to be more similar to a colour, i.e. a state that
>> one can change and that is applied to all following text until the next
>> state change. (Except that it's always reset at the end of the format
>> string.) The example above would then turn into '%w(72,8,4)%s%+b'.
>
> As a syntax to express "wrapping" behaviour alone, I think this is much
> simpler and more superiour. I guess with this if you want to wrap
> something to 72 columns and then wrap something else to 66 columns, you
> would write '%w(72,8,4)something%w(66,8,4)something else', right?
That's right.
> I used %] only for two reasons.
>
> - Without an explicit "here it ends", I couldn't come up with a good way
> to express '%[w(72,8,4)something%]something else'. IOW, how I can say
> "wrap something to 72 columns and then place something else without any
> wrapping"?
My patch makes '%w()' reset the wrapping parameters to their defaults.
> - When we need to support more than one string function like this, it is
> unclear what '%f()one string%g()another one' in your syntax means.
> Does it mean '%[f()one string%]%[g()another one%]' (i.e. concatenate
> the result of applying string function f to 'one string' and the result
> of applying string function g to 'another one')? Or does it mean
> '%[f()one string%[g()another one%]%]' (apply 'f' to concatenation of
> 'one string' and the result of applying 'g' to 'another one')?
I was going to say that we already have something like that with %C, and
that the natural way (to me) is to apply them both, independently. Case
modification functions (upper, lower, capitalized) could be treated the
same way -- as state changes (like pressing caps lock when typing text).
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?
But then something else hit me: the line wrap function needs to consider
colour codes as having a length of zero. Ugh.
René
next prev parent reply other threads:[~2009-10-18 8:25 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 [this message]
2009-10-18 22:47 ` Junio C Hamano
2009-10-19 23:07 ` René Scharfe
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=4ADAD0D2.504@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).