git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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é

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