[re-adding the list with permission]
On 11/18/19 3:17 PM, Ice Ninja wrote:
Hi Eric,
So the key thing here, looks to me, is the stream and the action of
collecting arguments phase is ignoring the stream where the text actually
is wrapped in.
The output stream is ONLY relevant to outer-most macro expansion. All
nested macro expansion during argument collection affect only what
argument is collected, not what is output.
I could work around the 'unexpected' or 'unituitive' behavior with
'ignore' definition like this,
enswan@ws/m4$ m4
<<<'changequote()changequote([,])define(ignore)include(ignore(good)show)'
m4:stdin:1: cannot open `show': No such file or directory
Yes, an ignore macro is one way to ignore arbitrary text regardless of
whether it is expanded as an outermost macro or as a nested expansion
during argument collection.
Shouldn't the argument expansion phase also respects the end result of the
expansion including respect the stream?
During argument collection, there is no output stream, only the argument
being collected. There are no diversions in play except during
outermost macros.
If not, when the argument itself is
an independent m4 script, the logic of 'running' that script will be
undergone a different mechanism which hence requires extra attention and
effort to deal with.
Parsing an m4 script in argument collection context is indeed different
than parsing the same script in top-level context. But that's an
inherent design limitation of the m4 language, so not something we can
really change.
I had no problem regards to the 1st m4 call in the last email,
enswan@ws/bin$ m4
<<<'changequote()changequote([,])divert(-1)good[]divert[]show'
show
I had it there was to show the inconsistency between the calls of m4 with
the same piece of code .
Do you have a bit feeling that my suggestion is reasonable or I should
correct myself entirely to 'think' in the way it is?
As I don't see m4 code changing, then it does seem like you'll have to
adjust your thinking on how argument collection works.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
