Print

Print


 > I don't follow you here. If the primitive isn't changed (which is what I
 > suggested) then everything which works today will continue to work (not
 > bomb), whereas if it is changed things may certainly bomb. By providing a

no it is the other way around. if, say, via inputenc we would be able
to specify that pressing the key a-umlaut generates \"a in text and
\ddot a in math (hope that exists :-) then using that in an array like macro
which doesn't handle the checking correctly, you will end up with \"a
inside math and that will bomb. thus you would need to update all such
uses of \halign to use \latex@halign istead.

 > fixed equivalent of the primitive, but not actually replacing it, package
 > writers can change their code to take advantage of these new macros and
 > thus have their code work in cases it previously didn't, whilst unchanged
 > code would continue to behave as it used to (most of the time work, but
 > fail in the odd cases discussed here).

the problem is that these aren't "odd" cases really. not when you go
and try to make every keyboard character usable everywhere. right now
essentially any keyboard key outside visible ascci is only allowed in
text mode so the problem doesn't arise (and the only problem that does
arise is the one when you try to write extended array syntax and try
to specify font encoding changes as part of the >{...} part.

 > PS: Pity Donald's solution didn't work. TeX probably ought to have been in
 > the "no mode" (like when expanding the text for a \write) when it is
 > looking for \noalign or \omit; then there would have been a test.

probably but even then it would be a kind of horrible test, wouldn't it? since there is no \ifnomode

frank