<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 16 Sept 2024 at 03:52, user202729--- via luatex <<a href="mailto:luatex@tug.org">luatex@tug.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Currently, if there's an input level that is ended, TeX will try to remove it as soon as it's finished. For example, the following will create an infinite loop.<br>
<br>
```<br>
\def\a{\b1}<br>
\def\b#1{\a}<br>
\a<br>
```<br>
<br>
Not so when `tex.cprint()` or `tex.sprint()` is involved. The following code causes a "TeX capacity exceeded" issue.<br>
<br>
```<br>
\def\a{\expandafter\b\directlua{tex.cprint(12,"1")}}<br>
\def\b#1{\a}<br>
\a<br>
```<br>
<br>
This causes a problem because internally LaTeX `\char_generate:nn` macro (sometimes) uses `tex.cprint()` under the hood, and this creates issue such as <a href="https://github.com/latex3/latex3/issues/1540" rel="noreferrer" target="_blank">https://github.com/latex3/latex3/issues/1540</a> .<br>
<br>
Do you think it would be reasonable modify the engine to pop the input level (i.e. call `end_token_list()`) of type `cprint` or `sprint` ? I think this is safe because, unlike the traditional reading from file with e.g. `\input`, there is no newline character in a line created with `tex.sprint` or `tex.cprint`, so there is no good reason to keep the empty suffix of a line behind.<br>
<br>
This may prove to be a nontrivial change however, because there are 7 calls to `end_token_list()` scattered throughout the code. (Although I think only the one call in `inputstack.c` and two calls in `expand.c` matters.)<br>
<br>
There might be performance implication as well because of the additional checking whether the token list ended --- although this may not be as large of a concern as it appears because we can simply move the check to only when the input limit is exceeded.<br>
<br>
What do you think?<br></blockquote><div><br></div><div>(sorry for the delay)</div><div>In these cases it's better to have a set of patches to discuss.</div><div>Of course, this set should fix a bug (but it doesn't seem the case here) </div><div>or, if not, it should not impact the performance and be backward compatible.</div><div><br></div><div><br></div><div>--</div><div>luigi</div><div><br></div><div><br></div></div></div>