[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, 04 Sep 2011 19:43:24 +0300

> Date: Sat, 3 Sep 2011 22:44:22 GMT
> From: address@hidden (Karl Berry)
> Cc: address@hidden, address@hidden
>     note the crucial detail that plagued "makeinfo -E": the macro
>     expansion must know about @ifset/@ifclear, and only expand those
>     parts that the user expects.  So a completely external solution will
>     probably not DTRT.
> I don't see it.  It seems to me it is exactly the other way around: a
> completely external solution is the only thing that *can* be reliable,
> because attempting to parse @ifXYZ will end up being tantamount to
> parsing the entire document.  Attempting to handle this is one of the
> things which made makeinfo -E (and texi2dvi -E) useless.

I don't think "makeinfo -E" tried to do that, but maybe I forget.

In any case, if we don't find a reasonable solution for this, we will
have a very similar problem on our hands, just with a different macro

> define([[mymac]], [[dnl
> @iftex
> do something for tex $1
> @end iftex
> @ifnottex
> another thing for everything else $2
> @end ifnottex
> ]])dnl
> mymac([[texstuff]], [[nontexstuff]])

This has some of the nastiest problems with macros: the white space
issue.  The Info format and the other formats treat white space
differently, so you need very different macro bodies for each case.
Having @if directives inside a macro adds more whitespace (the empty
lines left after expansion), and the solution to that problem, should
it become serious, is to have the @if outside of the macro.

In particular, sometimes there's a need to define a macro only for one
output format.

And what about macros that redefine existing commands?

> I really want an external solution, for all the reasons that have been
> discussed.  I am not attached to m4 specifically, but I don't see any
> better candidate.

I'm not against an external solution.  I'm saying that the experience
we've gathered till now should be carefully studied and summarized,
and then the new solution should be selected so as to build upon that
experience, not repeat it.

reply via email to

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