Cfrgtkky

I'm trying to automate the creation of some forms, and part of that
effort is automatically creating the correct number of blank rows in a
table-like form. That's led me to the following strange behavior:

documentclass{article}

usepackage{expl3}

usepackage{xparse}



ExplSyntaxOn

cs_new_eq:NN clistMap clist_map_inline:nn

ExplSyntaxOff



begin{document}

begin{tabular}{|ll|}

clistMap{one, two, three}{#1 &\hline}

end{tabular}



begin{tabular}{|ll|}

one &\hline

two &\hline

three &\hline

end{tabular}

end{document}

The two tables are typeset differently. I don't understand why.
There's a trailing row after the three rows in the first table. I say
a trailing row, because this following table is typeset the same as
the first.

begin{tabular}{|ll|}

    one &\hline

    two &\hline

    three &\hline

    \

end{tabular}

As one final pair of examples, as minimal as possible, note the same
appearance of the following two tables:

begin{tabular}{|ll|}

    clistMap{}{#1 &\hline}

end{tabular}



medskip % So you can see where one table ends and the other begins.



begin{tabular}{|ll|}

    \

end{tabular}

How do I get rid of this trailing newline? For bonus points---If you'd
be so kind, future answerers of mine---how would one detect that some
other unexpected control sequences are there? I tried using fancyvrb
commands to do it, and I could never quite get what I wanted; I wasn't
able to detect the \ control sequence, and other characters like
& caused problems. I also tried using the trace package, something
like clistMap expands to around 1000 lines of expanded macros.

You need to use clist_map_function:nN, defining a temporary function:

documentclass{article}



usepackage{expl3}

usepackage{xparse}



ExplSyntaxOn

NewDocumentCommand{clistMap}{mm}

 {

  cs_gset:Nn __beelzebielsk_map:n { #2 }

  clist_map_function:nN { #1 } __beelzebielsk_map:n

 }

ExplSyntaxOff



begin{document}



begin{tabular}{|l|l|}

hline

clistMap{one, two, three}{#1 &\hline}

end{tabular}

qquad

begin{tabular}{|l|l|}

hline

one &\hline

two &\hline

three &\hline

end{tabular}



end{document}

The problem with clist_map_inline:nn is that it leaves TeX in the state where a new cell has already been started when it realizes that the loop has ended.

This is actually what clist_map_inline:nn does: it defines a new “unnamed” function and does clist_map_function:nN with it. However it also has to cover its tracks, particularly for being usable also nested, and for this it uses a counter that has to be stepped down at the end: this is the operation that creates the unwanted additional row.

More explicitly: clist_map_inline:nn { <clist> } { <code> } roughly does

int_incr:Nn <reserved>_int

cs_gset:cn { <reserved> int_eval:n <reserved>_int :n } { <code> }

clist_map_function:nc { <clist> } { <reserved> int_eval:n <reserved>_int :n }

int_decr:Nn <reserved>_int

The function passed to clist_map_function:nc so depends on the nesting level, because the reserved counter is associated to clist mappings. This allows clist_map_inline:nn to contain in its second argument an inner clist_map_inline:nn, which will execute clist_map_function:nc with a different function.

However, the int_decr:Nn <reserved>_int operation will trigger, in your case, TeX starting a new cell. TeX tables are always rebellious beasts. ;-).

With the proposed definition, the operations on counters are skipped; of course you cannot nest clistMap in clistMap.

I am sure everyone will forgive my somewhat off-topic answer, and this is just to provide an example illustrating @egreg explanations:

documentclass{article}

usepackage{xinttools}

begin{document}

begin{tabular}{|ll|}

hline

xintFor #1 in {one, two, three}:

{#1 &\hline}

end{tabular}

begin{tabular}{|ll|}

hline

one &\hline

two &\hline

three &\hline

end{tabular}

end{document}

Although xintFor acts non-expandably, it is careful not to do anything "non vanishing by pure expansion" at its end. This allows it to not trigger accidentally a new row. This constraint does however have some limitation effect on the features of xintFor (see the boxed "15.17 xintifForFirst, xintifForLast" comments in xint.pdf).

Notice that the xintFor nests well.

A side remark here is about the strange "gaps" one sees (when magnifying) at the joining of horizontal and vertical lines in both (identical) tabulars: add usepackage{array} to fix that.

You could make the original function safe in this position by use of noalign

documentclass{article}

usepackage{expl3}

usepackage{xparse}



ExplSyntaxOn

cs_new_eq:NN clistMap clist_map_inline:nn

ExplSyntaxOff



begin{document}

begin{tabular}{|ll|}

noalignbgroupclistMap{one, two, three}{egroup#1 &\hlinenoalignbgroup}egroup

end{tabular}



begin{tabular}{|ll|}

one &\hline

two &\hline

three &\hline

end{tabular}

end{document}