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

[Carlos]

http://tug.org/mail-archives/texhax/2019-July/023762.html

On Tue, Jul 9, 2019 at 10:38 AM Paul Gessler <pdgessler at gmail.com> wrote:

> Hi Carlos,
>
> 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.
>
> 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.
>
> 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?
>
> Thanks,
>
> Paul
>
> On Tue, 9 Jul 2019 at 08:33, Carlos <linguafalsa at gmail.com> wrote:
>
>> Doug
>>
>> David Carlisle's recently had a request in which he asked me to stop this
>> because quote
>>
>> No please stop this, you clearly have no idea how to make a bug report
>> that anyone can act on.
>>
>> Endquote
>>
>> 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,...
>>
>> This issue apparently is getting to him...
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>>
>>
>> On Mon, Jul 8, 2019 at 7:10 PM Doug McKenna <doug at mathemaesthetics.com>
>> wrote:
>>
>>> Carlos -
>>>
>>> >| 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.
>>>
>>> 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.
>>>
>>> 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.)
>>>
>>> >| 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!
>>>
>>> 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.
>>>
>>> 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.)
>>>
>>> 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.
>>>
>>> Doug McKenna
>>> Mathemaesthetics, Inc.
>>>
>>> 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.
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/texhax/attachments/20190709/7e73e65d/attachment.html>