Re: Texinfo macros and m4

[Karl Berry]

Hi Ralf,

    rw> Any chance to get you to reconsider this decision?

I am not wedded to m4 specifically.  I just want something that works.

In short: I am well aware m4 has plenty of issues, but at least it is a
known quantity.  I've used it successfully with nontrivial TeX project
-- its use in documents is/would be far less complex, typically, than
autoconf m4 usage is.

To set the context:
1) very few Texinfo documents need macros at all.
2) of those that do need macros, @macro will continue to be available,
   and will suffice in many cases.
3) so we are talking about a tiny fraction of documents -- in reality,
   groff and lilypond are the only ones which come to mind.  In any
   case, people who work on such complex documents are not going to be
   afraid of delving into m4 peculiarities, nor find it easier to delve
   into Texinfo peculiarities.

I expect usage will grow over the years, as usage of @macro has.  Going
with m4 has the advantage that macro expansion is separated from
Texinfo.  Someone could conceivably put their own hacks into their own
personal m4, or invoke a completely different program -- it's none of
our business :).

    that avoids issues from the present @macro): what makes this infeasible?

A new macro scheme could in theory be devised.  I thought of using m4
because, well, in principle, specifying a new macro feature is hard, as
we have seen with @macro.  We'll surely end up with the same quoting
issues, etc.  I don't want to repeat the same mistake of whitewashing
over the complexity.  Nor do I want to reinvent m4, which is what I
think it would eventually come to.

Also, in practice, specifying and implementing a new macro feature would
take a significant effort; time which could be better spent elsewhere.

    Pointers appreciated.

It's been discussed on the mailing lists many times over the years, but
without any definitive resolution.  I have no urls at hand, sorry.

    eliz> I guess Karl hopes that Texinfo won't come anywhere near the
    complex uses of m4 that autoconf does.

Well, I don't kid myself that Werner won't find complex uses for m4 :).
But the point is, at least a) it's not a moving target like @macro,
and b) debugging and fixing becomes completely separable from Texinfo.

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

Fully agreed.

    Most of the problems are on the TeX side

Personally, I would say that "most" of the problems are with the design :).

But it is true that there is a fundamental TeX problem regarding newline
processing, conflicting with the fact that newlines-as-delimiter is a
critical part of the Texinfo language.  I won't bother going into the
TeXnicalities (again), instead I will just reiterate Eli's statement:

    In any case, the replacement macro-processor will have to be run by
    texi2xxx and produce TeX output without any trace of macros.  

Exactly.  Whatever the new macro facility is, whether m4 or something
homegrown, it will *not* be processed by texinfo.tex.  That would be of
no value whatsoever.

    There's a possibility to run the Texinfo input through "makeinfo -E"

There is (it was rms's idea), but as you say, it never worked well
enough in practice to be useful, unfortunately (or we wouldn't be having
this discussion).

    Come to think about it, what Texinfo needs is very similar to cpp.

For the reasons you cite, at least, I don't think cpp is a serious
contender.

If there is any other general-purpose macro expansion program in the
same area as m4 and cpp, I'd like to know.  I can't think of any.

Best,
karl