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

[Carlos]

>
> has been changed to \cr" error because it has changed that last
> alignment tab to \cr to satisfy the way the alignment was defined.
>

Not good enough. I don't think an error should occur.


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

> Thanks Carlos,
>
> David has already replied along the same lines but since I already
> started writing this, I'll send it along anyway.
>
> If I take that tabular example add a standard document class and wrap
> it in a document environment (I've removed the first row of the table
> as it's not relevant here):
>
> \documentclass{article}
>
> \begin{document}
> \begin{tabular}{cccc}
> para ver &&&& \cr} & & & &  % look at the closing brace and hence the
> missing \cr.
> \end{tabular}
> \end{document}
>
> The exact error message is
>
> ./carlos.tex:5: Extra alignment tab has been changed to \cr.
> <recently read> \endtemplate
>
> l.5 para ver &&&&
>                  \cr} & & & & % look at the closing brace and hence the
> mis...
>
> ?
>
> Because the tabular environment was declared with 4 columns, only 3
> alignment tabs are allowed per row, to separate the columns. On
> reading the fourth alignment tab, TeX issues the "Extra alignment tab
> has been changed to \cr" error because it has changed that last
> alignment tab to \cr to satisfy the way the alignment was defined.
>
> Your comment in the source code mentions the unmatched closing curly
> brace but in fact TeX has not yet read that far (you can see this
> based on where the line breaks in the error message).
>
> How do you propose that an error of too many alignment tabs in an
> alignment be handled instead of this way?
>
> Paul
>
>
> On Tue, 9 Jul 2019 at 09:44, Carlos <linguafalsa at gmail.com> wrote:
> >
> > 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/0586ff45/attachment.html>