TeX - ! Extra alignment tab has been changed to \cr

Carlos linguafalsa at gmail.com
Mon Jul 8 20:21:08 CEST 2019

Doug thank you so much for expressing it on human-readable terms. Something
I couldn't have accomplished.

(on an unrelated note no more than four days ago I read, about your
'Hilbert Curves'. from the last month thread, My most sincere
congratulations to you, for such creative material and for using Olsak's
macros, for whom deserved recognition of his work had not been acknowledged
(implemented) before - or if it was I'm not aware of.)   I disliked though,
that you never considered other platforms. But paraphrasing George Bernard
Shaw (no pun intended) 'if we exchange apples, each one will still have an
apple, but if we exchange ideas, each one will have two ideas.'  :)

The TeX error message doesn't talk about "newlines" because in a vertical
> alignment context, the *columns* (not the rows) are what's being being
> ended by a \cr (and because table cells can have multiple lines).  It
> wouldn't make sense, even though the TeX source code is "horizontalizing"
> the declaration of a vertical table.

Ironically, the only mention of newlines on the source code - or better put
from the TeXbook - concur with the above statement. That my friend, is
hilarious, yes, hilarious but not as funny per se, but as the oddest of
oddest things on the computing world. But then again, this will take me to
the following:

Page 239 and 294 \newlinechar (character that starts a new output line)

Furthermore, and this is where I don't want the following to be
misinterpreted is in that this discussion should not be about a newline
and/or carriage return historical implementations. But I'm afraid the
former sentence will slap a contradiction before I can even dare to finish:

For example, if you were to ask me right off the bat, whose implementations
and by drawing a comparison among the \settabs of Plain and the \tabular of
LaTeX makes any sense, any sense at all, it would be the former. Not
because is simply Knuth's, but simply because is vanilla, in which the
 complexity added by further macros that later became LaTeX, do not disturb
the engine.

But with the same token, I never ventured out to ask or read or research or
further look what computer had Knuth used for writing TeX, but the
implementation of a \cr obviously calls for a Macintosh. Perhaps is just a
mere coincidence, but what a coincidence that is, that the naming would
match such convention on that very particular system!

On Sun, Jul 7, 2019 at 9:32 PM Doug McKenna <doug at mathemaesthetics.com>

> Is not the problem that "newline" is both a character and a more general
> concept?
> After all, the etymology of \cr is from (c)arriage (r)eturn, and somewhat
> like a carriage return character in text, the purpose of a \cr is to tell
> the halign (valign) alignment context, either in the preamble or in later
> table content, in which it occurs that that context should start a new row
> (or column) in a horizontal (vertical) table, just like a carriage return
> can signify in certain similar situations elsewhere in the world.
> The TeX error message doesn't talk about "newlines" because in a vertical
> alignment context, the *columns* (not the rows) are what's being being
> ended by a \cr (and because table cells can have multiple lines).  It
> wouldn't make sense, even though the TeX source code is "horizontalizing"
> the declaration of a vertical table.
> As taken from TeX's WEB source, in an interactive environment, were the
> user to ask for a secondary "help" message after this particular error, TeX
> would output:
>    help3("You have given more \span or & marks than there were")@/
>    ("in the preamble to the \halign or \valign now in progress.")@/
>    ("So I'll assume that you meant to type \cr instead.");
> The point being, there's no principled way for TeX to extract itself from
> an anomalous situation, where two parts of an alignment context in a user's
> source code are declared inconsistently.  So TeX is choosing one course of
> action (presumably) under the assumption that it will cause less harm than
> the other choice.
> Note that this error message does not arise when the columns or rows of an
> alignment table are repeating (periodic).  The problem is that the preamble
> has declared a certain fixed number of columns (rows), but later source
> code has screwed up, attempting to use more than previously declared.
> For what it's worth, I consider this discussion as representative of a
> user-interface bug.  I made the decision in my own JSBox TeX language
> interpreter to do away with secondary help messages, in favor of more
> accurate first level messages, which use actual values and state known to
> the alignment context.  Generic error messages generally suck, but back in
> the day, generic error messages saved precious code space.  Here, the fact
> that no one has discussed the above-quoted secondary help message is
> basically part of the problem that arises when processing TeX code without
> stopping when an individual error occurs.
> For example, in a non-repeating \halign context with four columns (3
> dividing '&'s), the succinct message JSBox outputs in this situation is:
>   Found &.  The preamble for this \halign doesn't repeat and can't support
> more
>   than 4 columns.  Changing this & to a \cr.
> (substitute \span for & if that was the problem).  If this same situation
> occurred in a \valign context, \halign would be replaced by \valign, and
> the word "columns" would be replaced by "rows".  This kind of stuff is a
> pain to implement, but it's a lot more helpful to users.  Perhaps there are
> even clearer ways to express the problem.
> But those kind of adaptive error messages require a fair amount of extra
> code, which in turn changes line numbers, so it's really unlikely that
> anyone, Knuth or otherwise, is going to change anything in TeX's WEB code
> to clean this up.  I would predict that this particular user-interface
> issue (non-optimal communication with the user) is going to be a feature,
> not a bug, though I would be happy to be proved wrong.
> Doug McKenna
> Mathemaesthetics, Inc.
> ----- Original Message -----
> From: "Karl Berry" <karl at freefriends.org>
> To: linguafalsa at gmail.com, "texhax" <texhax at tug.org>
> Sent: Sunday, July 7, 2019 3:47:40 PM
> Subject: Re: TeX - ! Extra alignment tab has been changed to \cr
> Hi Carlos,
>      Extra alignment tab has been changed to \cr
>     When you ask an Anglophone speaking individual what from the above
> he/she
>     can understand from it,, that individual might reply - and rightly so -
>     that what the message conveys is that the \cr was applied to the
> newline,
> I disagree. Whatever the input was (I still can't make sense of your
> examples, sorry), that error message from TeX says nothing about
> newlines. It says that an extra alignment tab has been changed to
> \cr. And that is precisely what TeX did.
> In plain TeX (also in LaTeX, for that matter), alignment tabs are not
> newlines (unless the user him/herself made it so, which would be a
> strange thing to do), and there is nothing in The TeXbook to suggest
> that might be the case.
> I cannot speak about LaTeX, but speaking as the person who's charged
> with filtering bug reports to Knuth, I see nothing to send to him here.
> --best, karl.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/texhax/attachments/20190708/72ac042c/attachment.html>

More information about the texhax mailing list