conditional macros problem

[Werner LEMBERG]

[texinfo 4.8]

I want a macro @LE which produces a real less-than sign in TeX output
and `<=' everywhere else. I tried this simple version (which fails if
used within @math):

@tex
\gdef\LE{$\le$}
@end tex

@ifnottex
@macro LE
<=
@end macro
@end ifnottex

...

a @LE{} b

This works fine for both `makeinfo' and `tex'. Now my problem: I need
to pass --macro-expand to `makeinfo' before calling. Consequently, it
expands to

a <= b

instead of staying unexpanded.

Passing --iftex isn't a solution since I get fatal errors. Any ideas?

To make this work I can only imagine to introduce a new environment
`@emacro' which makes --macro-expand register the definition without
expanding the macro. In all other cases it behaves like @macro.

@tex
\gdef\LE{$\le$}
@end tex

@ifnottex
@emacro LE
<=
@end emacro
@end ifnottex


Werner

[Stepan Kasal]

Hi,

Post by Werner LEMBERG
@tex
\gdef\LE{$\le$}
@end tex
@ifnottex
@macro LE
<=
@end macro
@end ifnottex

for your information, gawk-3.1.4 documentation uses

@iftex
@set LEQ @math{@leq}
@end iftex
@ifnottex
@set LEQ <=
@end ifnottex

Post by Werner LEMBERG
Passing --iftex isn't a solution since I get fatal errors.

This is what should be fixed. makeinfo tries to parse contents of @tex,
which is not it's bussiness. Similar issue with @html, I guess.

Interestingly enough, all @ifxxx, @tex and @html sections seems to be
in the output of makeinfo -E. So the only problem is that makeinfo
thinks it might find a @macro definition in a @tex environment, which is
incredible.

So the fix might be fairly straightforward.
Would you volunteer for a patch? (I wouldn't, sorry.)

Have a nice day,
Stepan Kasal

[Eli Zaretskii]

Date: Wed, 9 Feb 2005 09:19:50 +0100

Post by Werner LEMBERG
Passing --iftex isn't a solution since I get fatal errors.

I don't see why this should be considered a bug. The Texinfo manual
clearly says that using the --ifFORMAT switch processes @ifFORMAT and
@FORMAT, so --iftex should indeed process @tex.

In other words, it's a feature.

[Stepan Kasal]

Hi,

Post by Eli Zaretskii

Date: Wed, 9 Feb 2005 09:19:50 +0100

Post by Werner LEMBERG
Passing --iftex isn't a solution since I get fatal errors.

I don't see why this should be considered a bug. The Texinfo manual
@FORMAT, so --iftex should indeed process @tex.
In other words, it's a feature.

Well, it's an unimplemented feature...
makeinfo parses the content of @tex as if it were written in the Texinfo
language. But the code is written in the TeX language.

To meet the documentation makeinfo would have to be able to interpret the
TeX language, ie. contain most of TeX embedded.

As this is not reasonably doable, we have to fix both the documentation
and the code. We can throw the @tex blocks away under some circumstances,
or we can pass them to the output, but in all cases we have to take them
as black boxes.

Yours,
Stepan

[Eli Zaretskii]

Date: Fri, 11 Feb 2005 15:25:37 +0100

Post by Eli Zaretskii
I don't see why this should be considered a bug. The Texinfo manual
@FORMAT, so --iftex should indeed process @tex.
In other words, it's a feature.

Well, it's an unimplemented feature...
language. But the code is written in the TeX language.

That doesn't mean unimplemented, only that the implementation could be
improved.

To meet the documentation makeinfo would have to be able to interpret the
TeX language, ie. contain most of TeX embedded.

No, it just needs to skip the whole @tex block and output it verbatim.

[Stepan Kasal]

Hi again,
exactly, this is what I had in mind since the beginning.
Sorry for the confusion.

Stepan

[Werner LEMBERG]

Post by Stepan Kasal

Post by Werner LEMBERG
Passing --iftex isn't a solution since I get fatal errors.

This is what should be fixed. makeinfo tries to parse contents of
@tex, which is not its bussiness. Similar issue with @html, I
guess.
be in the output of makeinfo -E. So the only problem is that
environment, which is incredible.

What --iftex must do is to `register' macro definitions within @tex
environments, at least if option -E is active. So it has to somehow

Post by Stepan Kasal
So the fix might be fairly straightforward.

For people who have enough insight, yes -- unfortunately, I don't have
yet.


Werner

[Karl Berry]

parse the contents of @tex to recognize `\gdef\foo#1{...}' being a macro
definition for @foo{...} which must not be expanded.

It's obviously not going to do that. The most makeinfo can do is read
@tex chunks as (effectively) verbatim text and ignore them. It can't
possibly try to parse TeX.

I've totally lost track of the problem.

I'm adding @le and @ge. If that doesn't solve it, let me know.

k

[Werner LEMBERG]

Post by Karl Berry
It's obviously not going to do that.

Why not? Where's the problem? Currently, --iftex fails for most code
in @tex environments. We can impose restrictions how raw TeX macros
must look like to make them easily parseable by makeinfo.

Post by Karl Berry
I've totally lost track of the problem.

It is helpful, but it doesn't solve the issue. To reiterate:

. Macro @foo shall produce a typographically enhanced symbol if used
with TeX output. Let's assume that texinfo doesn't provide direct
access, so we have to use a @tex environment to create a raw TeX
definition of @foo.

. For all other output modes, a simple solution using @macro shall
be provided.

Normally this works fine if you simply say `@tex \gdef\foo{...} ...'
and `@ifnottex @macro foo ...'. Unfortunately, this method fails if
you use `makeinfo -E'.

Fortunately, I've just found a working solution using @set (thanks for
the hint)!

@tex
\gdef\LEmacro{$\le$}
@end tex

@iftex
@set LEmacro @LEmacro
@end iftex

@ifnottex
@set LEmacro <=
@end ifnottex

@macro LE{}
@value{LEmacro}
@end macro


Now `a @LE{} b' works with both `makeinfo' and `makeinfo -E', and it
gives the typographically correct result if processed with TeX. Maybe
this should be documented...


Werner

[Eli Zaretskii]

Date: Fri, 11 Feb 2005 00:50:44 +0100 (CET)

Post by Karl Berry
It's obviously not going to do that.

Why not? Where's the problem?

The problem is that what you suggested requires to teach makeinfo
about a large chunk of the TeX language. That is not going to happen.

We can impose restrictions how raw TeX macros
must look like to make them easily parseable by makeinfo.

You will be the first to complain about such limitations ;-)

[Karl Berry]

I've just found a working solution using @set

Excellent. I will see about documenting this.

We can impose restrictions how raw TeX macros
must look like to make them easily parseable by makeinfo.

We can't restrict @tex, its whole point is to allow writing arbitrary
TeX code.

But I am still interested in such restrictions, for the sake of having a
new macro syntax that can be easily implemented in TeX and thus not
require makeinfo -E and all its concomitant problems.

My basic idea is something like this:

@newmacro @foo @***@arg2{***@arg1...whatever...}

where texinfo.tex has \let\arg=#. Then \newmacro maps to \def.
Should be simpler for makeinfo, too.

But I am not sure how to handle line endings. Since so many TeX
commands are line-oriented ...

(The real name would not be @newmacro, that's just for the sake of example.)

Thanks,
karl

[Werner LEMBERG]

Post by Karl Berry
Excellent. I will see about documenting this.

A minor problem is that any definition of a symbol with @set makes it
a \mathord (due to the group around it). So it is still useful to add
@le and @ge for correct mathematical spacing.

Post by Karl Berry
@newmacro @foo @***@arg2{***@arg1...whatever...}
where texinfo.tex has \let\arg=#. Then \newmacro maps to \def.
Should be simpler for makeinfo, too.
But I am not sure how to handle line endings. Since so many TeX
commands are line-oriented ...

You mean line endings at interpretation time, right? Then I suggest
that `@macro foo' isn't allowed but must always be `@macro foo{}'. I
can't see an advantage to define a macro which eats the space after
it. Or do you mean something different?


Werner

[Karl Berry]

@le and @ge for correct mathematical spacing.

Drat. I wondered about that. Ok, back on the list it goes.

I can't see an advantage to define a macro which eats the space
after it.

I agree, and I was imagining that braces would always be required, both
for the definition and the call.

Or do you mean something different?

Yes, I mean something like this:
@newmacro @mymac {
line1
line2
@quotation
whatever
@end quotation
}

The problem is that commands like @quotation are delimited by an ^^M
char, so ^^M will have to be active when the @newmacro definition is
read. But ^^M shouldn't always mean a new line, of course -- e.g., the
one after line1. I'm not sure exactly what the implications are, but I
doubt it will be fun.

Interaction with conditionals will also probably be near-impossible.
Sigh.

But here's the real stumper for me: how to handle calling macros when
there's more than one arg. Usual Texinfo convention is the stupid comma
separation, as in @bigmac{actual1,actual2,actual3}. This is not easily
parsable with TeX, but we definitely want to use TeX's builtin argument
parsing or we'll be nearly as bad off as we are now. The closest we can
come is delimited args:
@newmacro @bigmac @arg1,@arg2,@arg3{...whatever...}

Which could be called like @bigmac actual1,actual2,{actual3} ...
not really nicely integrated with the rest of the language, or fun to
implement in makeinfo. Well, maybe we can strip off outer braces
at each call and let TeX do the rest.

Just have to set it up and do some testing, I guess.

Cheers,
karl

[Werner LEMBERG]

Post by Karl Berry
@newmacro @mymac {
line1
line2
@quotation
whatever
@end quotation
}
read. But ^^M shouldn't always mean a new line, of course -- e.g.,
the one after line1. I'm not sure exactly what the implications
are, but I doubt it will be fun.

What do you think about having two macros, say, @NewMacro and
@NewMacroWithActiveNewline to handle those issues in a clean way?

Post by Karl Berry
Usual Texinfo convention is the stupid comma separation, as in
@bigmac{actual1,actual2,actual3}. This is not easily parsable with
TeX, but we definitely want to use TeX's builtin argument parsing or
we'll be nearly as bad off as we are now. The closest we can come
@newmacro @bigmac @arg1,@arg2,@arg3{...whatever...}

Ugly. Why not using TeX syntax directly?

@newmacro @bigmac @arg1 @arg2 @arg3 { ... }

(or something similar) to be called as

@bigmac{actual1}{actual2}{actual3}...


Werner

[Karl Berry]

What do you think about having two macros, say, @NewMacro and
@NewMacroWithActiveNewline to handle those issues in a clean way?

May be necessary to resort to that. But if a macro needs both active
and normal newlines ... maybe the answer is an @newline{} (or whatever)
command which means "active newline". Hmm. Have to try.

Post by Karl Berry
@newmacro @bigmac @arg1,@arg2,@arg3{...whatever...}

Ugly. Why not using TeX syntax directly?

Obviously desirable for TeX. Not desirable for makeinfo, or from the
standpoint of the Texinfo language design (such as it is), since it's a
new argument specification syntax not otherwise used. Again, may be
necessary to resort to that, nevertheless.

Thanks for the ideas.

[Stepan Kasal]

Hi,

Post by Karl Berry
@newmacro @mymac {
line1
line2
@quotation
whatever
@end quotation
}
read. But ^^M shouldn't always mean a new line, of course -- e.g., the
one after line1. [...]

OK, so the main problem is that we too often change parsing rules during
the run of TeX. In other words, we use \catcode too often.

In order to be able to change parsing rules in the middle of @macro, we
use the \scantokens primitive of e-TeX (or its emulation in TeX).
This is what makes things ugly.

The main problem is the difference between places where ^M is endline
and where it's active. It would be nice if we were able to find a
definition of ^M which would work in normal text--producing \par on an
empty line and space otherwise (but without making a double space if
the line ended with a space). But as this is not possible, we have to
switch the \catcode often. And to get @macro's right, we have to save
them with ^M remembered, ie. the catcode of ^M cannot be end-of-line,
and we have to use \scantokens.

So this hack is not going to be removed from texinfo.tex, unless...

Unless we state that @macro's _must_ be expanded by makeinfo before we
run tex. That would save us a lot of work.

Let me attack the same problem from another angle:
LaTeX users often wonder why
\newenvironment{myverb}
{\begin{verbatim}}
{\end{verbatim}}
doesn't work.

They ask this question, because their perception is that the LaTeX
_first_ expands _their_ defined macros, and then it processes the result.
This is not true, of course. I see this as the main reason why LaTeX
cannot succeed with its attempt to build a new, different, consistent
macro language over the (inconsistent) language of TeX.

We have the same misunderstanding here at texinfo, with @macro's.
People imagine that @macro's are expanded first, and then the result
is processed. But luckily, _we_ can accept that view and do it indeed
that way. As I said, this would save us lot of trouble.

If we go that way, the whole ugly code for @macro's will go away from
texinfo.tex, replaced by a simple error message pointing to texi2dvi.
(texi2dvi would execute makeinfo -E --iftex, which has to be fixed first,
of course.)

Some instances of \scantokens would still remain in texinfo.tex, eg. for
@copying/@insertcopying. Now, when we require pre-processing by makeinfo,
we can handle those the same way: makeinfo -E would remove @copying and
replace @insertcopying by the actual text.

One more final note: texinfo.tex changes catcodes on too many places.
I explained that the main problem with the catcode of ^M cannot be
eliminated, but there are many other problems, eg. with changing catcodes
for indices and toc. The following cleanup would be very helpful:
1) identify the various catcode states ("state" means a vector of 256
catcode values) which could appear when running texinfo.tex
2) identify when can which state be rached and make the changes between
those states clearer
3) identify states which can be eliminated, eg. by changing the format
of auxiliary files, and make the changes to eliminate them.

Changes to the way input is parsed are dangerous and should be used
only if necessary, and in a transparent way.

Well, I'm afraid I will never find time to implement this. ;-)

Have a nice day,
Stepan

[Eli Zaretskii]

Date: Sat, 26 Feb 2005 16:05:50 +0100
So this hack is not going to be removed from texinfo.tex, unless...
run tex. That would save us a lot of work.

But it will add a lot of work to makeinfo maintainers, I'm afraid.

[Werner LEMBERG]

we run tex. That would save us a lot of work.

While I agree that this solves many problems, it has the main drawback
that a foo.texinfo document no longer can be processed without
makeinfo, and I think this is not acceptable.

Perhaps a compromise is a better solution: Leave @macro as-is and
introduce a new command, say, @macrox, which needs makeinfo for
expansion. In case we do so, the limitations of @macro should be
completely documented so that the user exactly knows when to use
@macrox is unavoidable.


Werner

[Eli Zaretskii]

Date: Sun, 27 Feb 2005 08:15:03 +0100 (CET)
While I agree that this solves many problems, it has the main drawback
that a foo.texinfo document no longer can be processed without
makeinfo, and I think this is not acceptable.
expansion.

As I already said here, I don't think it's a good idea to introduce a
macro facility that requires "makeinfo -E", because that will reveal
other problems. (I know that because there was time when texinfo.tex
didn't support macros, which forced people to use "makeinfo -E". The
results were so unsatisfactory that the addition of macro support to
texinfo.tex was embraced as a panacea. Let's not repeat past
mistakes.)

[Stepan Kasal]

Hello,

Post by Eli Zaretskii

Post by Werner LEMBERG
While I agree that this solves many problems, it has the main drawback
that a foo.texinfo document no longer can be processed without
makeinfo, and I think this is not acceptable.

?? No, I didn't meant this. Plain "makeinfo" would still work.
I just meant that "makeinfo -E" would have to be run before running TeX.

Post by Eli Zaretskii
As I already said here, I don't think it's a good idea to introduce a
macro facility that requires "makeinfo -E", [...] Let's not repeat past
mistakes.
[...] the addition of macro support to
texinfo.tex was embraced as a panacea.

OK, I wasn't here at the time this happened.

In that case we are pretty much stuck with what we have. The TeX @macro
implementation has to use \scantokens, so we cannot do much here.

What I could do, is to fix "makeinfo -E" so that even if it won't be
required for macros, using it will be a good workaround for many people.

Thank you, Eli,
Stepan

[Eli Zaretskii]

Date: Mon, 28 Feb 2005 15:16:13 +0100
What I could do, is to fix "makeinfo -E" so that even if it won't be
required for macros, using it will be a good workaround for many people.

That should be always welcome, I think.

TIA

[Karl Berry]

@le and @ge for correct mathematical spacing.

1) Don't you have to use @math for that anyway? (Your example didn't
show that.) Getting math spacing outside of math mode would not be fun.

2) You could force the right kind of atom with \mathrel (in this case).
But I'm not sure this is the problem.

Maybe something like this:

@tex
\gdef\LEmacro{\ifmmode\else$\fi \le \ifmmode\else$\fi}
@end tex

And then:
@math{a @LE{} b}

The \ifmmode stuff is so it will work both in and out of math mode.

I admit I haven't tried it -- just woke up with the idea.

Cheers,
karl

[Werner LEMBERG]

Post by Werner LEMBERG
@le and @ge for correct mathematical spacing.
didn't show that.) Getting math spacing outside of math mode
would not be fun.

My original code indeed uses @le in @math. I've just made the example
simpler by adding two `$' characters.

Post by Werner LEMBERG
2) You could force the right kind of atom with \mathrel (in this
case). But I'm not sure this is the problem.

The very problem is that I have to use @set and @value to circumvent
the `makeinfo -E' problem. Anything defined with @set is put into a
group while expanding with @value. Adding \mathrel would be fine, but
makeinfo doesn't understand this -- and within the @set group it has
no effect.


Werner

[Karl Berry]

within the @set group it has no effect.

Yeah. It's so frustrating that - and _ can't be in TeX control words.

How about using \aftergroup in the \LEmacro?

\gdef\LEmacro{\aftergroup\le}

(Assuming for the moment it's only used in @math ...)
I'll try it when I have a chance, just had the idea.

k

[Werner LEMBERG]

Post by Karl Berry
How about using \aftergroup in the \LEmacro?
\gdef\LEmacro{\aftergroup\le}

This doesn't work, but if I use seven \aftergroup, I get the correct
result. Thanks for the idea!


Werner

[Stepan Kasal]

Hi,
no, we cannot interpret every TeX code possible.
Searching for

\\[egx]def\\[A-Za-z]+([^{}]*#[1-9])*{
and
\\let\\[A-Za-z]+

to catch TeX definitions is possible, but very fragile.
Perhaps the hack is to redefine something from plain.tex or texinfo.tex...

We should really give up and not interpret @tex blocks.

The preprocessed file _will_ be interpreted by TeX, right? So what's the
problem? (Or, more exactly, what would be the problem if `makeinfo --iftex'
were fixed the way I proposed?)

Have a nice day,
Stepan Kasal

[Eli Zaretskii]

Date: Wed, 09 Feb 2005 05:41:07 +0100 (CET)
@tex
\gdef\LE{$\le$}
@end tex
@ifnottex
@macro LE
<=
@end macro
@end ifnottex
...
This works fine for both `makeinfo' and `tex'. Now my problem: I need
to pass --macro-expand to `makeinfo' before calling. Consequently, it
expands to
a <= b
instead of staying unexpanded.
Passing --iftex isn't a solution since I get fatal errors. Any ideas?

The Texinfo conditional facilities include @ifset and @ifclear. You
can control those with the "-D FOO" command-line switch to makeinfo.
You could use the -D switch together with --macro-expand to get
makeinfo expand only those parts that you want.

Does that help you get what you want?

[Karl Berry]

Sorry, I did get this message after all. I didn't realize it had been
sent earlier today!

I want a macro @LE which produces a real less-than sign in TeX output

In this case, I think by far the simplest solution is to define @le{}
and @ge{} as real Texinfo commands. Although we can't easily define
every math character, clearly these two are extremely common, so
defining them seems reasonable. That much is easy to do, and I'll work
on out.

As Eli said, trying to define an @emacro command will probably create
worse headaches than it solves.

The more general solution is to make texi2dvi work for this case, by
avoiding the @[if]tex parse errors. That should not be too hard. Way
easier than @emacro anyway.

(The most general solution is to fix macros, but I'm tired of saying
that. :)

Best,
karl