At 22.33 +0100 2001-02-02, Frank Mittelbach wrote:
>Lars wrote:
[snip]
> > What I suspect is the right solution is to have \protect set to
> > \@unexpandable@protect when scanning for \omit and have it reset to

Actually, after thinking about it a bit more I think it should be
\noexpand\protect rather than \noexpand\protect\noexpand; there's no need
for the extra \noexpand as the expansion is stopped at the first thing
which is \noexpand'ed.

> > \@typeset@protect in the column template---then the robustness mechanisms
> > for normal robust commands, text commands, and in the \IeC command
> > respectively would take care of sorting things out. I doubt this can be
> > done by patching the \halign primitive, but it could be built into e.g. the
> > array package.
>
>yes, that would solve the problem i'm pretty sure of it but as i said in my
>earlier mail this really doesn't help because it would then only work in array
>but not in, any contributed package that uses \halign (this is why Vladimir
>tries to patch \halign).
>
>perhaps one should investigate combining your solution (change of protect)
>with a patch to \halign after all, eg via a clever use of \everycr and the
>like.

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

\latex@halign[<glue_0>]{ ... \do[<glue_i>]{<template_i>} ... }
  <body>
\latex@endhalign

and have it work sort of like

\tabskip=<glue_0>
\halign{ ... &<template_i>\tabskip=<glue_i>& ... \cr
  <body>
\crcr}

but also do the (ii) above (so there would probably be a <hack> prepended
to each <template_i>). The <glue> arguments are optional in case you don't
want to set the \tabskip glue (but occurs to me that an explicit \NoValue
would be more appropriate for this level). The idea is that since we don't
try to invent a new syntax for the <template>s it wouldn't be that hard to
change an existing package to take advantage of the new features, while
keeping the primitive untouched for those (few?) applications which really
need it that way and those which really don't need (ii).

Lars Hellström