<div dir="ltr">Doug thank you so much for expressing it on human-readable terms. Something I couldn't have accomplished.<br><br>(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.'  :)<div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br></blockquote><br><div><br></div></div><div>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:<br><br>Page 239 and 294 \newlinechar (character that starts a new output line)<br><br><br>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:<br><br>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.<br><br>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!<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 7, 2019 at 9:32 PM Doug McKenna <<a href="mailto:doug@mathemaesthetics.com">doug@mathemaesthetics.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Is not the problem that "newline" is both a character and a more general concept?<br>
<br>
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.<br>
<br>
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.<br>
<br>
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:<br>
<br>
   help3("You have given more \span or & marks than there were")@/<br>
   ("in the preamble to the \halign or \valign now in progress.")@/<br>
   ("So I'll assume that you meant to type \cr instead.");<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
For example, in a non-repeating \halign context with four columns (3 dividing '&'s), the succinct message JSBox outputs in this situation is:<br>
<br>
  Found &.  The preamble for this \halign doesn't repeat and can't support more<br>
  than 4 columns.  Changing this & to a \cr.<br>
<br>
(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.<br>
<br>
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.<br>
<br>
<br>
Doug McKenna<br>
Mathemaesthetics, Inc.<br>
<br>
<br>
----- Original Message -----<br>
From: "Karl Berry" <<a href="mailto:karl@freefriends.org" target="_blank">karl@freefriends.org</a>><br>
To: <a href="mailto:linguafalsa@gmail.com" target="_blank">linguafalsa@gmail.com</a>, "texhax" <<a href="mailto:texhax@tug.org" target="_blank">texhax@tug.org</a>><br>
Sent: Sunday, July 7, 2019 3:47:40 PM<br>
Subject: Re: TeX - ! Extra alignment tab has been changed to \cr<br>
<br>
Hi Carlos,<br>
<br>
     Extra alignment tab has been changed to \cr<br>
<br>
    When you ask an Anglophone speaking individual what from the above he/she<br>
    can understand from it,, that individual might reply - and rightly so -<br>
    that what the message conveys is that the \cr was applied to the newline,<br>
<br>
I disagree. Whatever the input was (I still can't make sense of your<br>
examples, sorry), that error message from TeX says nothing about<br>
newlines. It says that an extra alignment tab has been changed to<br>
\cr. And that is precisely what TeX did.<br>
<br>
In plain TeX (also in LaTeX, for that matter), alignment tabs are not<br>
newlines (unless the user him/herself made it so, which would be a<br>
strange thing to do), and there is nothing in The TeXbook to suggest<br>
that might be the case.<br>
<br>
I cannot speak about LaTeX, but speaking as the person who's charged<br>
with filtering bug reports to Knuth, I see nothing to send to him here.<br>
--best, karl.<br>
</blockquote></div>