TeX - ! Extra alignment tab has been changed to \cr
Paul Gessler
pdgessler at gmail.com
Tue Jul 9 16:38:24 CEST 2019
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/42512c16/attachment-0001.html>
More information about the texhax
mailing list