<div dir="ltr"><a href="http://tug.org/mail-archives/texhax/2019-July/023762.html">http://tug.org/mail-archives/texhax/2019-July/023762.html</a><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 9, 2019 at 10:38 AM Paul Gessler <<a href="mailto:pdgessler@gmail.com">pdgessler@gmail.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"><div dir="ltr">Hi Carlos,<div><br></div><div>Being a totally disinterested party so far, I too still do not fully understand the problem you are reporting. There are a number of partial examples in this thread, and the link you provided to a previous thread doesn't have a complete example in the particular message you linked to. There were some plain TeX examples, but I understood that the original problem was with a LaTeX document. </div><div><br></div><div>I apologize if I've missed it in a quote or somewhere else, but I did not yet find a complete compilable LaTeX example that results in the error message in question. So far, the only complete LaTeX documents I've seen in this thread and the other do not result in the misplaced alignment tab error message. </div><div><br></div><div>I acknowledge that it's entirely possible I've missed it in an older message or in a quote somewhere. If so, sorry for that. For my own benefit and for the list, could you please re-share the complete example file, along with what you expect to happen instead of the misplaced alignment tab error message?<div><br></div><div>Thanks,</div><div><br></div><div>Paul</div><div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 9 Jul 2019 at 08:33, Carlos <<a href="mailto:linguafalsa@gmail.com" target="_blank">linguafalsa@gmail.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"><div dir="ltr">Doug <div><br></div><div>David Carlisle's recently had a request in which he asked me to stop this because quote<br><br>No please stop this, you clearly have no idea how to make a bug report<br>that anyone can act on.<br><br>Endquote<br><br>Even though I already provided a report and better than his. But he requested to stop from posting about this issue any longer, and that's fine,...<br><br>This issue apparently is getting to him...<br><br>But I'll catch up with your latest message later. And yes, I agree with your prior statement that  quote *columns* (not the rows) are what's being being ended by a \cr  endquote.<br><br>After reading carefully your prior message, I noticed you made it seemed though as if there's the possibility of an error, and a non-error. But this issue can't be both. it's an either or.<br><br>If by stitching up with the right amount of code to mitigate the problem, it would entails a shortcut, this however, doesn't make the error less error after than before when it was patched up. How would pathcing it would rule out the fact that the error was not there. If it weren't, no patching would have been needed. <br><br>Likewise, fixing the implementation based on the error, makes the error further ratify that it was indeed an error before and after that needed to be patched up.<br><br>So one could deny that there is an error, which is a form of deceiving oneself in the process, or else one could admit that there's no error, so deceiving oneself would not occur. What is the fact? But there's indeed an error of `Extra alignment tab has been changed to \cr`. So for those who have denied all along that there's an error,  this error is some form of deceiving oneself. Heck with it, I always thought that the error is in itself an error, for the simple fact thtat it does not belong to exist during compilation of the document but just as transparent and clear to reflect is true meaning during the compilation. <br><br>As it is, it obscures the fact that it was not meant to be an error, but rather error-free as the intention was supposed to be.<br><br><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 8, 2019 at 7:10 PM Doug McKenna <<a href="mailto:doug@mathemaesthetics.com" target="_blank">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"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div><div style="font-family:arial,helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)"><div>Carlos -<br></div><br><div>>| For example, if you were to ask me right off the bat, whose</div><div>>| implementations and by drawing a comparison among the</div><div>>| \settabs of Plain and the \tabular of LaTeX makes any sense,</div><div>>| any sense at all, it would be the former. Not because is simply</div><div>>| Knuth's, but simply because is vanilla, in which the  complexity</div><div>>| added by further macros that later became LaTeX, do not disturb</div><div>>| the engine.<br></div><br><div>I don't know much about the innards of various macro packages, but the whole point of the TeX language is that such packages are essentially language extensions.  Although such packages can have their own level of testing against inconsistencies and bad input, it's not easy for a high-level macro to know when the TeX interpreter has reported a low-level error.  The point being that if a higher-level set of macros (in LaTeX or plain or opmac or wherever) is allowing an inconsistency that is not being caught at that high level before presenting whatever state to the low-level, pedal-to-the-metal TeX interpreter, the low-level error message is not going to be as helpful as a user would want.</div><br><div>But it is not the low-level TeX interpreter's responsibility to fix the situation (i.e., a bug), it is the higher-level macro library's responsibility.  (In a perfect world, that is.)</div><br><div>>| I never ventured out to ask or read or research or further look</div><div>>| what computer had Knuth used for writing TeX, but the</div><div>>| implementation of a \cr obviously calls for a Macintosh.</div><div>>| Perhaps is just a mere coincidence, but what a coincidence</div><div>>| that is, that the naming would match such convention on that</div><div>>| very particular system!<br></div><br><div>It is true that Classic Macintosh files ended lines with a single carriage return character, instead of the historical CR-LF sequence from the teletype days, and instead of using a linefeed character as became the standard in Unix systems.  They're now all kind of merged into the single idea of a "newline" ('\n') in computer code.</div><br><div>But Knuth wrote much of TeX long before there was a Macintosh (and a usable Macintosh didn't happen until 1986 or later, depending on one's definition of "usable").  He and his colleagues were undoubtedly using mainframes and/or minicomputers at the Stanford Computer Science Dept.  Recall that they actually hacked the Pascal compiler at the time so as to be able to record TeX subroutine call usage statistics.  I'm not sure how possible that would have been on a Mac at that time, because users didn't have access to the Pascal compiler's source (One reason that Apple's early Macintosh team settled on using Pascal was because the UCSD compiler was free, whereas licensing a C compiler at that time would have cost a couple of hundred bucks.  Sigh.)<br></div><br><div>Knuth unified the newline mess by creating a character category called "end of line" (internally, using catcode 5).  But all such raw input characters are only temporary, because end-of-line characters (whatever they are) get converted at a very low level during interpretation into either a space character or, when paired, a command called \par (paragraph).  Internally, Knuth created a symbol in the WEB source code, "car_ret" for this category, and then *reused* that symbol value (5) at a higher level to represent the \cr and \crcr primitive alignment commands in the language, for no particular reason other than they were conceptually related (one less symbol to declare).  But as I wrote previously, the higher level \cr and \crcr commands don't have anything really to do with line ends.  They have to do with row or column ends in a horizontal or vertical alignment context.<br></div><br><div>Doug McKenna<br></div><div>Mathemaesthetics, Inc.<br></div><br><div>P.S. The reason my recently released self-typesetting eBook isn't on other platforms has to do with its extremely complicated graphics, not with its typesetting library, which is system-agnostic in the extreme.<br></div></div><br></div></div></div></blockquote></div>
</blockquote></div>
</blockquote></div>