behaviour of functions like \str_if_eq:nnTF if interrupted by \endinput

[u-fischer]

The following document

\documentclass{article}
\begin{document}
\ExplSyntaxOn
\begingroup
\aftergroup\endinput\endgroup\str_if_eq:nnTF{env}{file}{blub}{blub} \show\x
\ExplSyntaxOff
\end{document}

gives when compiled with pdflatex or xelatex

> \x=undefined.
l.29 ..._if_eq:nnTF{env}{file}{blub}{blub} \show\x

but with lualatex and the new luacall implementation one gets a missing number error:

! Missing number, treated as zero.
<to be read again> 
=
l.29 ...\endinput\endgroup\str_if_eq:nnTF{env}{file}
                                                  {blub}{blub} \show\x
? x

This is a problem for the standalone package which issues an \aftergroup\endinput, and so now fails with lualatex
https://sourceforge.net/p/standalone/tickets/2/

[josephwright]

Isn't the issue here that inserting \endinput where anything is on the same line is always an issue?

[u-fischer]

well the issue is imho that normally if you issue \endinput the commands on the same line are still processed (it goes to the \show\x for pdflatex) but in luatex it ends somewhere in the middle of a command. That is rather unpredicatable behaviour isn't it?

(I don't think that exactly this is happening in standalone, only that the error is due to a similar problem with \endinput/code order).

[FrankMittelbach]

Am 04.10.20 um 12:18 schrieb Joseph Wright:

Isn't the issue here that inserting |\endinput| where anything is on the same line is /always/ an issue?

The behavior of \endinput with respect to other stuff on the current line is defined (and not random) so if it differs in one engine then this sounds to me like an engine implementation bug.

[josephwright]

One for @zauguin I guess