texinfo-devel
[Top][All Lists]
Advanced

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

Re: m4 lines handled everywhere?


From: Karl Berry
Subject: Re: m4 lines handled everywhere?
Date: Thu, 27 Oct 2011 23:06:52 GMT

    I think that it should be enabled in the default case.  

Agreed then.

    Then people could use something like
    @w{}#line aaa.h

First, there should be "quotes" around aaa.h there and an integer before
it -- without the quotes and the integer, it shouldn't be recognized as
a #line directive.  The minimal valid forms are basically:
# 1 "a.b"
#line 1 "a.b"
#line 1 "a.b" 1
(It would be good to peruse the cpp output from hello.c.  Lots of
complicated things there.)

Anyway, yes, @w should usually suffice.  But I think we should also
make a simple command @numbersign{} to generate the # character, to
avoid any chance of misprocessing.  Imagining multiple front-end passes
and the @w{} getting eliminated at some point ...


(Aside: Not related to #line, but I've been thinking we may as well make
@backslashchar{} too, since \ is foolishly part of @macro syntax.  Ok?)

    I think it depends on what TeX would do with the lines directives.  

I have no feasible way to implement that kind of finicky parsing in
texinfo.tex.  So a #line is going to be processed as normal Texinfo
input.  (Outputting #, l, i, ...).

      @cpplinedirectives on/off

So texinfo.tex has no way to implement that either.
(They are always off.)

Besides that, introducing an @ command for this seems like it has great
potential for complication: the directive itself could be embedded in
complicated macros or whatever and it would highly unclear as to what
was intended.  So I think in this one case, a cmdline option/init
setting/whatever is the better way.

The only reliable way I see to embed a directive in the source file
would be to do it on the \input texinfo line, but when I was speculating
about enabling m4 or not that way on the list, nobody seemed to like the
idea.  But maybe for this more limited on/off, it would be ok.

That is, the implementation I am imagining is a new "zeroth" pass which
purely and simply scans the text as text, looking for (and removing)
these #lines and not recognizing anything else.  Then the regular
parsing takes over on the result.  Somehow actually taking account of
the #line information for diagnostic msgs, of course.

karl



reply via email to

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