Re: [PATCH 3/3] Add proof-of-concept %[w(width,in1,in2)<<any-string>>%] implementation

From: Jakub Narebski <jnareb@gmail.com>
Date: Oct 16, 2009, 18:02 UTC
Message-ID: <m33a5jfc6p.fsf@localhost.localdomain>
In-Reply-To: <7vk4yvuu79.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 8 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
>> maybe "rewrap" would be a better name than "w"?
> 
> Perhaps, but I do not know if wrap() is even better.  The only reason I
> said w() here is because I saw you used w() and this is meant to be a
> superset replacement for it, as this can re-wrap anything, not just one
> particular field from the commit object.

wrap(initial_prefix, subsequent_prefix, columns) would for example follow somewhat Text::Wrap syntax, together with 'fill'. With columns being 0, not set, or negative it could simply indent result; this way we finally would be able to get default git-log / git-rev-list format using --pretty format.

I don't remember what were original parameters to w(72,4,8) means...

Show 18 quoted lines

> 
>> On Fri, 16 Oct 2009, Junio C Hamano wrote:
>>
>>>   #1 "%[" introduces the nested string function.
>>> 
>>>   #2 After that, a name identifies what function to call.
>>> 
>>>   #3 The function parses its parameters ("(72,4,8)" in the above example),
>>>      and makes a nested expansion on the remainder of the format string.
>>
>> Can't we parse it once, i.e. the first time?
> 
> I may be missing the issue you are raising here, but it parses the string
> only once; it stuffs the expansion of the enclosed string into a separate
> buffer (while noting where it ends), applies the function to the result
> obtained in the separate buffer and appends the result of the function
> application to the main buffer, and the main expansion resumes where the
> nested one finished.

Do I understand it correctly that generic syntax is the following:

  %[function(params) format specifiers]

which would run given function, with given extra parameters, on the result of expansion of the rest of the group? That is a very powerfull syntax... I wonder how other tools solved such problem...

BTW. can we have this also for git-for-each-ref format parameter?

Note that for single parameter we have different syntax (for git-for-each-ref), namely

  %(field:modifier)

which could be expanded to allow for parametrized modifiers with one of the following:

  %(field:modifier=param)
  %(field:modifier[param])
  %(field:modifier(param))

-- 
Jakub Narebski
Poland
ShadeHawk on #git