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

[Carlos]

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/c16e2983/attachment-0001.html>