texinfo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

commas and two-argument macros


From: Karl Berry
Subject: commas and two-argument macros
Date: Thu, 13 Sep 2012 18:03:05 GMT

    Date: Wed, 25 Jul 2012 10:21:28 +0200
    ...
    @macro mactwo{argfirst, argsecond}
    \argfirst\ ... \argsecond\
    @end macro
    @mactwo{Fran@,cois}.

    ... To me the texi2any behaviour is more logical, macros are
    expanded leaving the @-commands untouched, and only after their
    expansion is the Texinfo code expanded.  The question is should we
    say something about that in the manual?

I added some text to the manual -- it seems to boil down to another
macro limitation for TeX.

I did not try to trace exactly what texinfo.tex is doing in this case,
it gives an error and that's all that really matters here.  Since
\-escapes of commas in macro calls don't work in texinfo.tex, that means
there is no way to directly pass an argument with the @, command to
multiple-argument macros.  Fortunately a work-around using @set/@value
works, as far as I can tell.

I can agree that it's reasonable for texi2any to split at the comma,
thus passing the two arguments "Fran@" and "cois".

As a side note, texi2any's character-based macro processing is
completely and utterly different from TeX's token-based macros.  Let's
replace " ... " in the above with letters:
    @macro mactwo{argfirst, argsecond}
    \argfirst\BetweenArgs\argsecond\AfterArgs
    @end macro
    @mactwo{Fran@,cois}.

texi2any's error is:
mac-comma.tex:8: Unknown command `BetweenArgscoisAfterArgs' (possibly involving 
@mactwo)

i.e., it has constructed a new command name starting with the @ before
the comma in the macro call and then interweaving all the following
letters in the macro call and definition.  Logical in its way, but so so
different.

I did not attempt to explain that in the manual, since any macro that's
intended to work in both implementations couldn't use such features
anyway, and I doubt we want to guarantee the behavior, anyway.  I'm not
sure if even m4 operates that way (without an explicit eval, anyway).

Thanks,
k



reply via email to

[Prev in Thread] Current Thread [Next in Thread]