"! Undefined control sequence. <argument> \fail" after update. But what package?

[Alexander Krumeich]

Everybody,

thanks for the feedback! Once again, I must say.

It turned out that the "\fail" macro was buried deeply within my own
code. That part used to work, but apparently upstream changes in
another package caused this to fail now. It'll take some research on
my part to find out what the exact cause was. Sorry for taking up your
time.

It learned a couple of things today:

The importance of an MWE. Thanks to Markus and Ulrike for pointing
that out. The second thing is the command line option and
\errorcontextlines macro to narrow down the place where the error is.
These are very helpful hints for debugging situations like this in the
future.

Best regards

   Alexander

On Fri, Jan 7, 2022 at 2:46 AM Don Hosek <don.hosek at gmail.com> wrote:
>
> Actually trying this out, I see the problem. The feature is implemented to produce the output in the wrong place:
>
> Without the flag, the output is, e.g.:
>
> ! Undefined control sequence.
> l.16 \qognbo
>
> With the flag the output is:
>
> ./xx.tex:16: Undefined control sequence.
> l.16 \qognbo
>
> This indicates that it was put into the definition of print_err (which has no indication that modifying it is a valid extension of TeX) instead of show_context (which does have that indication), and it really does belong in show_context just as a matter of logic and semantics.
>
> -dh
>
> On 6 Jan 2022, at 14:31, David Carlisle <d.p.carlisle at gmail.com> wrote:
>
>
>
> On Thu, 6 Jan 2022 at 20:10, Don Hosek <don.hosek at gmail.com> wrote:
>>
>> > As your document errors in the preamble, providing an MWE is really
>> > easy. At least provide the full log until the error so that one has
>> > at least a chance to identify the package.
>>
>> It occurs to me that the means by which TeX identifies the location of an error is not so great when many input files are involved (especially with nested \input commands). Perhaps there should be a change to the output[1] of an error location from
>>
>> > l.112   {}{\fail}
>>
>> to
>>
>> > file.tex: l.112   {}{\fail}
>
>
> that is already available as --file-line-error  command line option in all texlive engines.
>
> David
>
>>
>> We can do this by modifying s.313 so that it does:
>>
>> > print(input_stack[base_ptr].name_field); print_nl(“l.”); print_int(line);
>>
>> instead of
>>
>> > print_nl(“l.”); print_int(line);
>>
>> Unless there’s some compelling reason not to, this seems like something that could/should have been done long ago.
>>
>> -dh
>>
>> ——
>>
>> 1. I had originally thought that this would need to be an eTeX extension but I see that Knuth writes:
>>
>> > This routine should be changed, if necessary, to give the best possible indication of where the current line resides in the input file.
>>
>