-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Ralf Wildenhues on 10/17/2008 1:05 PM:
> Overall very nice, only nits. Thanks!
Applied, with these changes:
>
>> Subject: [PATCH] Add AS_VAR_COPY.
>>
>> +# AS_VAR_SET(VARIABLE, VALUE)
>> +# ---------------------------
>> +# Set the VALUE of the shell VARIABLE.
>> +# If the variable contains indirections (e.g. `ac_cv_func_$ac_func')
>> +# perform whenever possible at m4 level, otherwise sh level.
>
> This sentence is hard to understand; I'd guess:
>
> +# If VARIABLE contains indirections (e.g. `ac_cv_func_$ac_func'),
> +# perform indirection at the m4 level whenever possible, otherwise
> +# at the sh level.
That was pre-existing text, moved down in the file. I've floated all the
macro moves into a separate patch (turning the series of 3 into 4), then
reworded this to state:
# Set the contents of the polymorphic shell VARIABLE to the shell
# expansion of VALUE.
>> Subject: [PATCH] Test AS_VAR interfaces.
>
>> +AT_SETUP([AS@&[EMAIL PROTECTED])
>> +AT_KEYWORDS([m4sh AS@&[EMAIL PROTECTED] AS@&[EMAIL PROTECTED] AS@&[EMAIL
>> PROTECTED]
>> +AS@&[EMAIL PROTECTED] AS@&[EMAIL PROTECTED] AS@&[EMAIL PROTECTED]
>> AS@&[EMAIL PROTECTED]
>> +AS@&[EMAIL PROTECTED])
>
> FWIW, you can use multiple AT_KEYWORDS instead of wrapping, too.
Sure, and that reads a little better. Changed.
>
>> --- a/NEWS
>> +++ b/NEWS
>
> s/\n/ /g | fmt ?
> (but you can do that in an independent patch if you prefer)
Sure; it matches prior release notes.
>> +Often times, it is convenient to write a macro that will emit shell code
>
> s/ times// ?
Done.
>> +M4sh supports the notion of polymorphic shell variables, making it easy
>> +to write a macro that can deal with either literal or indirect variable
>> +names and output shell code appropriate to both use cases. Behavior is
>
> appropriate for?
Yes, that sounds better.
>> [EMAIL PROTECTED]), then @var{if-not} is expanded. The implementation is
>> +somewhat conservative (for example, @samp{'[$]'} is a single-quoted
>> +shell literal, but causes @var{if-not} to be expanded), in order to
>> +offer speed to the common case of deciding whether a variable name is
>
> speed for?
I went with:
In order to reduce the
time spent deciding whether an expression is literal, the implementation
is somewhat conservative (for example, @samp{'[$]'} is a single-quoted
shell literal, but causes @var{if-not} to be expanded). While this
macro is often used for recognizing shell variable names, it can also be
used in other contexts.
>
>> [EMAIL PROTECTED] AS_VAR_IF (@var{var}, @ovar{value}, @ovar{if-match},
>> @ovar{if-diff})
>
> if-equal and if-not-equal?
That does sound nicer.
>> +into a valid shell name by @code{AS_TR_SH}. In order to access the
>> +composed variable name based on @var{value}, it easier to declare a
>
> s/it /&is /
Thanks for catching all my grammar slip-ups.
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkj5BuUACgkQ84KuGfSFAYCA2ACfTtuAYQH+K0y4UFcqUaTJ0C20
7f8AoIGaw9vSz5iYt75tUeZ1Lk+N57Z6
=8Yq6
-----END PGP SIGNATURE-----
