LATEX-L Archives

Mailing list for the LaTeX3 project


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Mailing list for the LaTeX3 project <[log in to unmask]>
Lars Hellström <[log in to unmask]>
Fri, 9 Feb 2001 14:43:55 +0100
Mailing list for the LaTeX3 project <[log in to unmask]>
text/plain (46 lines)
At 12.41 +0100 2001-02-08, Frank Mittelbach wrote:
> > 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.

Exactly what happens depend on how the text \"a is implemented (with the T1
implementation and CM math the character simply is lost with no error
message, whereas with OT1 implementation the \accent might well get TeX to
believe that you've lost a $), but I don't think the errors are serious
enough to qualify as a "bomb" (at a Mac, a "bomb" is the last error message
before the system dies). Certainly these errors should be fixed (if
possible), but one can live with them. On the other hand, I think that the
error caused by an \edef\@tempa{\halign to \the\dimen@} with \halign being
the mathtext redefinition rather than the primitive can qualify as a bomb.

> > 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.

I was thinking more in the lines of odd = "rarely occuring in existing

> > 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

Is \ifhmode\else \ifvmode\else \ifmmode\else \relax \fi\fi\fi that
horrible? There are much fewer tokens than in \@inmathwarn.

Lars Hellström