On Mon, Sep 05, 2011 at 11:07:02AM +0300, Eli Zaretskii wrote:
> > It will do the macro expansion everywhere in the document.
> > Except in headings and in @tex, @html, ignored @iftex/@if*/@ifset...
>
> What happens with macros that have @if... conditionals in their body?
@if are not parsed when
> Date: Mon, 5 Sep 2011 09:43:23 +0200
> From: Patrice Dumas
>
> On Sun, Sep 04, 2011 at 11:04:35PM +0300, Eli Zaretskii wrote:
> >
> > Please tell the details of "do right" in this situation.
>
> It will do the macro expansion everywhere in the document.
> Except in headings and in @tex, @html
On Sun, Sep 04, 2011 at 11:04:35PM +0300, Eli Zaretskii wrote:
>
> Please tell the details of "do right" in this situation.
It will do the macro expansion everywhere in the document.
Except in headings and in @tex, @html, ignored @iftex/@if*/@ifset...
--
Pat
Eli Zaretskii writes:
>> From: Ben Pfaff
>> Cc: k...@freefriends.org, bug-texinfo@gnu.org
>> Date: Sun, 04 Sep 2011 18:23:25 -0700
>>
>> Then why is there a problem with macro expansions?
>
> I tried to explain that earlier, see
>
> https://lists.gnu.org/archive/html/bug-texinfo/2011-08/msg00
> From: Ben Pfaff
> Cc: k...@freefriends.org, bug-texinfo@gnu.org
> Date: Sun, 04 Sep 2011 18:23:25 -0700
>
> Then why is there a problem with macro expansions?
I tried to explain that earlier, see
https://lists.gnu.org/archive/html/bug-texinfo/2011-08/msg00031.html
> Is the solution to just
Eli Zaretskii writes:
>> From: Ben Pfaff
>> Date: Sun, 04 Sep 2011 10:51:46 -0700
>> Cc: bug-texinfo@gnu.org
>>
>> Why not just have texi2dvi run the Texinfo source through
>> "makeinfo --macro-expand" before running it through TeX?
>
> texi2dvi already does that.
Then why is there a problem w
> Date: Sun, 4 Sep 2011 21:08:40 +0200
> From: Patrice Dumas
>
> On Sun, Aug 28, 2011 at 09:29:50AM -0400, Eli Zaretskii wrote:
> >
> > 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, an
On Sun, Aug 28, 2011 at 09:29:50AM -0400, Eli Zaretskii wrote:
>
> 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. Perhap
> From: Ben Pfaff
> Date: Sun, 04 Sep 2011 10:51:46 -0700
> Cc: bug-texinfo@gnu.org
>
> Why not just have texi2dvi run the Texinfo source through
> "makeinfo --macro-expand" before running it through TeX?
texi2dvi already does that.
k...@freefriends.org (Karl Berry) writes:
> Regarding macros in general. I've been trying, and I have become
> skeptical that there is any way to devise a new Texinfo macro command
> that does not run afoul of many of the same issues. In particular, TeX
> cannot precisely control behavior at newl
> Date: Sat, 3 Sep 2011 22:44:22 GMT
> From: k...@freefriends.org (Karl Berry)
> Cc: ralf.wildenh...@gmx.de, bug-texinfo@gnu.org
>
> note the crucial detail that plagued "makeinfo -E": the macro
> expansion must know about @ifset/@ifclear, and only expand those
> parts that the user ex
> From: Thien-Thi Nguyen
> Cc: e...@gnu.org, ralf.wildenh...@gmx.de, bug-texinfo@gnu.org
> Date: Sun, 04 Sep 2011 10:41:37 +0200
>
> Maybe better would be to drop @macro entirely.
I think it's too late for such a radical step backwards. The current
facility has its drawbacks, but it _is_ usef
() k...@freefriends.org (Karl Berry)
() Sat, 3 Sep 2011 22:44:22 GMT
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.
Introducing ability to call out to m4 (or whatever) also int
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:
> There's a possibility to run the Texinfo input through "makeinfo -E"
> first,
groff needs this, BTW.
>@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
> Date: Sun, 28 Aug 2011 23:58:39 GMT
> From: k...@freefriends.org (Karl Berry)
> Cc: bug-texinfo@gnu.org
>
> 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
Sigh, sorry for the extra msg, but I forgot to mention that I will be
mostly offline this coming week, so I probably won't be able to
contribute more to the discussion until I'm back on Saturday.
k
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
> From: Ralf Wildenhues
> Date: Sun, 28 Aug 2011 12:15:03 + (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
Hello,
Karl Berry writes:
>
> 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-b
Well, up to now it is possible (in almost all cases) to process
texinfo documents with TeXLive out of the box to get a PDF,
Well, not exactly (see below), but in any case, as far as I can see
nothing in this regard changes by introducing an optional call to m4.
First, virtually no Texinfo
> I don't mind having an indication for m4 usage in a comment line of
> its own. But combining it with an Emacs Local Variable line or
> section sounds really bad.
Oops, the last sentence might be ambiguous. Please add
... if you don't follow the convention for Local Variables.
Werner
> Sounds reasonable. However, if you do that, m4 *must* become part of
> TeXLive!
>
> Gee. I totally disagree! It is not TL's business to provide system
> utilities. The resulting conflicts are a true pain. Even getting it to
> build on our all platforms, in a way that works in the bu
I'm all for it!
Thanks :).
Using m4 as preprocessor will make Texinfo extremely powerful.
That's what I was thinking too :).
The default quotes should perhaps be redefined, because ``..'' used in
Texinfo would conflict with them.
Right, sigh. I had forgotten that m4 stripped
What about implementing a solution with luatex? Would that work?
No. I mean, sure, it could work for people using luatex, but
a) luatex will be a moving target for quite some time to come, and
b) a vanishingly small percentage of people use it, and
c) it would take quite a lot of development
> Regarding macros in general. I've been trying, and I have become
> skeptical that there is any way to devise a new Texinfo macro
> command that does not run afoul of many of the same issues. In
> particular, TeX cannot precisely control behavior at newlines, and
> newline-delimited commands ar
Karl Berry ha escrit:
> 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'm all for it! Using m4 as preprocessor will make Texinfo ext
Werner and all,
Regarding macros in general. I've been trying, and I have become
skeptical that there is any way to devise a new Texinfo macro command
that does not run afoul of many of the same issues. In particular, TeX
cannot precisely control behavior at newlines, and newline-delimited
comman
28 matches
Mail list logo
