LATEX-L Archives

Mailing list for the LaTeX3 project

LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

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
Sender:
Mailing list for the LaTeX3 project <[log in to unmask]>
Subject:
From:
Lars Hellström <[log in to unmask]>
Date:
Thu, 8 Feb 2001 12:05:23 +0100
In-Reply-To:
Reply-To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Parts/Attachments:
text/plain (36 lines)
At 22.19 +0100 2001-02-07, Frank Mittelbach wrote:
> > One variant would be to start offering LaTeX-variants of \halign and
> > \valign which (i) has less corny syntax, (ii) takes care to prevent errors
> > of the kind discussed, and (iii) might offer a few extra features (e.g.
> > calc-like syntax for \tabskip glue specifications or something; I don't
> > know if that might be useful). What I'm thinking of is that you could write
> > something like
>
>Lars,
>
>while a suggestion like this would perhaps be an improvement for package/class
>writers it wouldn't solve the update problem i was talking about; and if you
>rely on code only working correctly if no straight \halign is arround
>accepting arbitrary text, then this is a real problem.
>
> find /cdrom/texmf/tex/latex -type f -exec grep -l halign {} \;
>
>alone gives you 67 packages/classes that have \halign in their code (well to
>be exact have "halign" somewhere in their text :-), many many more would be
>out there and all of them would suddenly bomb if not updated

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

Lars Hellström

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.

ATOM RSS1 RSS2