Mdthbs

I defined a newenvironment with this code (sample):

documentclass{article}

usepackage[utf8]{inputenc}

usepackage{amsthm}



newenvironment{myEnv}[1][default]

{

   pushQED{#1}

   expandaftercsname x#1 endcsname

}

{    expandaftercsname endxpopQED endcsname    }



newenvironment{xdefault}{}{}



begin{document}



begin{myEnv}

end{myEnv}



end{document}

I need this for some stuff later to call a specific environment using the argument. But I get the following error in Overleaf:

Missing endcsname inserted.



<to be read again> 

               begingroup 

l.35 end{myEnv}



The control sequence marked <to be read again> should

not appear between csname and endcsname.

-----------

Extra endcsname.



endmyEnv ...after csname endxpopQED endcsname 



l.35 end{myEnv}



I'm ignoring this, since I wasn't doing a csname.

As far as I can tell, the csname/endcsname's should be correct, I don't see an error, so I have no idea what causes this. When I searched the error I only found topics that were unrealated to my example.

Does someone know how to fix this?

Try something like

documentclass{article}

usepackage[utf8]{inputenc}



% make sure tssavedarg is not taken already

newcommand*{tssavedarg}{}

newenvironment{myEnv}[1][default]

  {deftssavedarg{#1}%

   csname x#1endcsname}

  {csname endxtssavedargendcsname}



newenvironment{xdefault}{XX}{YY}



begin{document}



begin{myEnv}

A

end{myEnv}



end{document}

pushQED and popQED are specifically for QED handling in amsmath and they seem to implement a full QED stack, which you do not need. In particular popQED does not simply expand to the contents saved with pushQED, so it does not work within csname ... endcsname as expected.

In your case it is enough to just save the #1 in a normal macro with def and then retrieve the macro value by calling it.

Related Why can't the end code of an environment contain an argument?.

The xparse/LaTeX3 solution would be

usepackage{xparse}

NewDocumentEnvironment{myEnv}{O{default}}

  {csname x#1endcsname}

  {csname endx#1endcsname}

or maybe even more expl3-y

usepackage{xparse}

ExplSyntaxOn

NewDocumentEnvironment{myEnv}{O{default}}

  {use:c{x#1}}

  {use:c{endx#1}}

ExplSyntaxOff

because xparse's environments can access the arguments even in the end code.

Let's see how pushQED and popQED are defined in amsthm.sty:

    274 DeclareRobustCommand{qed}{%

    275   ifmmode mathqed

    276   else

    277     leavevmodeunskippenalty9999 hbox{}nobreakhfill

    278     quadhbox{qedsymbol}%

    279   fi

    280 }

    281 letQED@stack@empty

    282 letqed@eltrelax

    283 newcommand{pushQED}[1]{%

    284   toks@{qed@elt{#1}}@temptokenaexpandafter{QED@stack}%

    285   xdefQED@stack{thetoks@the@temptokena}%

    286 }

    287 newcommand{popQED}{%

    288   begingroupletqed@eltpopQED@elt QED@stackrelaxrelaxendgroup

    289 }

    290 defpopQED@elt#1#2relax{#1gdefQED@stack{#2}}

    291 newcommand{qedhere}{%

    292   begingroup letmathqedmath@qedhere

    293     letqed@eltsetQED@elt QED@stackrelaxrelax endgroup

    294 }

The name clearly shows that this has to do with the typesetting of the QED marker in proofs, so I included the definition of qed.

There is a “stack”, actually a macro, called QED@stack, that's initialized to empty.

Suppose we call pushQED{foo} when the stack is empty. Two scratch token registers are set: first toks@ is set to qed@elt{foo}, then @temptokena is set to contain the current first level expansion of QED@stack (in this case, nothing). Next, QED@stack is redefined to contain the token lists in the two registers; with e-TeX extensions, this could be achieved with the single instruction

xdefQED@stack{unexpanded{qed@elt{#1}}unexpandedexpandafter{QED@stack}}

So now QED@stack will expand to qed@elt{foo}. If another pushQED{bar} follows, the expansion would become qed@elt{bar}qed@elt{foo}. But let's stay with the simple case.

What happens when popQED is called? The instructions at line 288 are executed, namely

begingroupletqed@eltpopQED@elt QED@stackrelaxrelaxendgroup

The macro qed@elt (that normally is relax, see line 282) is set to mean popQED@elt inside a group and then QED@stackrelaxrelax is examined. In your case it is

qed@elt{foo}relaxrelax

Since the macro qed@elt has been redefined, this is the same as popQED@elt{foo}relaxrelax and, according to the definition of popQED@elt,

#1 <- {foo}

#2 <- 

and therefore

foogdefQED@stack{}relax

would remain in the main token list (the braces are stripped off by rule of TeX). In case QED@stack had been qed@elt{bar}qed@elt{foo}, we'd have

#1 <- {bar}

#2 <- qed@elt{foo}

and bargdefQED@stack{qed@elt{foo}}relax would be pushed into the main input stream.

Just the fact that the expansion of popQED begins with begingroup disqualifies it from being legal inside csname...endcsname; moreover assignments cannot be performed in that context, so it's a lost battle to begin with.

The double relax is in case the stack is empty at the time popQED is called, that is without a matching pushQED command.

What's the main usage of the system? The standard proof environment in amsthm.sty is defined as

    432 newenvironment{proof}[1][proofname]{par

    433   pushQED{qed}%

    434   normalfont topsep6p@@plus6p@relax

    435   trivlist

    436   item[hskiplabelsep

    437         itshape

    438     #1@addpunct{.}]ignorespaces

    439 }{%

    440   popQEDendtrivlist@endpefalse

    441 }

The idea is that a subordinate proof environment might define its own tombstone symbol and push it in the stack, so at end environment the right symbol would be used.

Can you use stacks for this purpose? Yes.

documentclass{article}

usepackage{xparse}



ExplSyntaxOn



NewDocumentCommand{newstack}{m}

 {

  seq_new:c { g_thorsten_#1_stack_seq }

 }



NewDocumentCommand{push}{mm}

 {% #1 is the stack's name, #2 the item to push

  seq_gpush:cn { g_thorsten_#1_stack_seq } { #2 }

 }



NewDocumentCommand{pop}{mo}

 {% #1 is the stack's name, #2 what you should do with the top item

  % reinitialize, in case it has been modified

  cs_set_eq:NN __thorsten_stack_exec:n __thorsten_stack_exec_default:n

  IfValueT{ #2 }

   {

    cs_set:Nn __thorsten_stack_exec:n { #2 }

   }

  seq_gpop:cNTF { g_thorsten_#1_stack_seq } l__thorsten_stack_item_tl

   {% if the stack is not empty

    __thorsten_stack_exec:V l__thorsten_stack_item_tl

   }

   {% if the stack is empty, issue an error

    __thorsten_stack_exec:n { STACKEMPTYERROR }

   }

 }



tl_new:N l__thorsten_stack_item_tl

cs_new_protected:Nn __thorsten_stack_exec_default:n { #1 }

cs_set_eq:NN __thorsten_stack_exec:n __thorsten_stack_exec_default:n

cs_generate_variant:Nn __thorsten_stack_exec:n { V }



ExplSyntaxOff



newstack{env}



newenvironment{myEnv}[1][default]

 {%

  push{env}{#1}%

  csname x#1endcsname

 }

 {%

  pop{env}[csname endx##1endcsname]%

 }



newenvironment{xdefault}{par start}{finishpar}

newenvironment{xinner}{par startinner}{finishinnerpar}



begin{document}



begin{myEnv}

begin{myEnv}[inner]

end{myEnv}

end{myEnv}



newstack{foo}



push{foo}{A}

push{foo}{B}

push{foo}{C}



pop{foo}[@@#1@@]

pop{foo}[??#1??]

pop{foo}[!!#1!!]

pop{foo}[---#1---]



end{document}

The push command takes as arguments the stack's name and the item to push. pop takes as mandatory argument the stack's name and the optional argument is a template for what to do with the popped item (default is to just deliver it) after removing the item from the top of the stack.

Be careful with spaces in your input: csname x#1 endcsname is not the same as csname x#1endcsname.

Since in the last example the pop operation is called on an empty stack, an error is produced

! Undefined control sequence.

<argument> STACKEMPTYERROR 



l.69 pop{foo}[---#1---]