[Top][All Lists]

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

Re: Texinfo macros and m4

From: Eli Zaretskii
Subject: Re: Texinfo macros and m4
Date: Sun, 28 Aug 2011 09:29:50 -0400

> From: Ralf Wildenhues <address@hidden>
> Date: Sun, 28 Aug 2011 12:15:03 +0000 (UTC)
> > Patrice and I haven't had a chance to discuss this in detail yet, but at
> > present it seems to me that the most robust plan would be to simply
> > provide an option to run the document through m4 before Texinfo. 
> I wouldn't be too happy if you went that way.  The in-band signaling
> is terrible, we have a lot of experience from autoconf, not entirely
> positive, on how complex it is for users to understand m4 quoting
> issues well, and how it very complex to pass arbitrary inputs through
> m4.

I guess Karl hopes that Texinfo won't come anywhere near the complex
uses of m4 that autoconf does.  Not sure whether these hopes are real,
given the ingenious uses of @macro I've seen over the years...

In any case, I personally welcome your input wrt this issue.  TIA.

> Apologies for being ignorant of the principal issues you've had with
> properly defining macros from within texinfo (possibly with a new API
> that avoids issues from the present @macro): what makes this infeasible?

Most of the problems are on the TeX side, because originally TeX was
supposed to process the Texinfo input all by itself, including @macro
expansion.  Karl knows much more about that than I do, so I'll leave
it to him to elaborate.

There's a possibility to run the Texinfo input through "makeinfo -E"
first, which expands the macros and is supposed to leave everything
else intact, and texi2dvi even uses it (I think), but somehow this
isn't enough.  Perhaps nested macros are not expanded? or maybe the
problem was with conditional macros surrounded by @ifset/@ifclear,
which "makeinfo -E" didn't process? I don't remember anymore.

As for the makeinfo side, here are the issues I remember:

 . The quoting issue

   @macro arguments are separated by commas, but sometimes you need to
   pass an argument that includes a literal comma.  You are supposed
   to be able to do that by escaping the comma with a backslash, but
   this raises problems when a macro calls another macro.  Similar
   problems happen with using literal backslashes -- the Groff manual
   suffers from this problem.

   A related problem is caused by the fact that macro arguments are
   used by enclosing them between 2 backslashes, as in \arg\.

 . The whitespace issue

   Empty lines are significant in Texinfo and are preserved in Info
   and plain text output formats.  A single newline and any sequence
   of blanks are _usually_ insignificant, but sometimes they are.
   E.g., in @example or after @*.  Since a @macro is normally defined
   in more than one line, i.e.

     @macro foo{p1, p2, p3}
     @something \p1\
     @something-else \p2\ \p3\
     @end macro

   there's the issue with the newlines before and after the body.  A
   typical nuisance is that you cannot easily write a single macro
   that will work both in @example and in the normal environment,
   because there are contradicting requirements wrt keeping or
   removing the newlines.

 . There's no equivalent of #ifdef, so you cannot easily test whether
   a macro you need has already been defined.

 . It is impossible to have a macro that defines another macro.
   Also, you cannot have "@macro" without the matching "@end macro",
   or vice versa, inside a macro.  This precludes writing dynamic
   macros, and forces users to write multiple fixed versions of macros
   depending on some @ifset/@ifclear magic.

These are what I remember, I'm sure Werner will come up with a few
more annoyances.

At least some of these are entirely due to how @macro is implemented
in makeinfo -- a single-pass translator that expands each macro on the

Come to think about it, what Texinfo needs is very similar to cpp.
But there are a few differences that need to be carefully considered:

 . whitespace is insignificant in C, but not in Texinfo

 . cpp usage doesn't need to pass arguments with embedded commas

 . Texinfo macros can be recursive

 . probably a few more

In any case, the replacement macro-processor will have to be run by
texi2xxx and produce TeX output without any trace of macros.  This
will have to overcome all the difficulties that "makeinfo -E" didn't,
or else it will be doomed from the get-go.


reply via email to

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