Xjyuk

I defined a newenvironment with this code (sample):

documentclassarticle
usepackage[utf8]inputenc
usepackageamsthm

newenvironmentmyEnv[1][default]

 pushQED#1
 expandaftercsname x#1 endcsname

 expandaftercsname endxpopQED endcsname 

newenvironmentxdefault

begindocument

beginmyEnv
endmyEnv

enddocument

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 endmyEnv

The control sequence marked <to be read again> should
not appear between csname and endcsname.
-----------
Extra endcsname.

endmyEnv ...after csname endxpopQED endcsname 

l.35 endmyEnv

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

documentclassarticle
usepackage[utf8]inputenc

% make sure tssavedarg is not taken already
newcommand*tssavedarg
newenvironmentmyEnv[1][default]
 deftssavedarg#1%
 csname x#1endcsname
 csname endxtssavedargendcsname

newenvironmentxdefaultXXYY

begindocument

beginmyEnv
A
endmyEnv

enddocument

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

usepackagexparse
NewDocumentEnvironmentmyEnvOdefault
 csname x#1endcsname
 csname endx#1endcsname

or maybe even more expl3-y

usepackagexparse
ExplSyntaxOn
NewDocumentEnvironmentmyEnvOdefault
 use:cx#1
 use:cendx#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 DeclareRobustCommandqed%
 275 ifmmode mathqed
 276 else
 277 leavevmodeunskippenalty9999 hboxnobreakhfill
 278 quadhboxqedsymbol%
 279 fi
 280 
 281 letQED@stack@empty
 282 letqed@eltrelax
 283 newcommandpushQED[1]%
 284 toks@qed@elt#1@temptokenaexpandafterQED@stack%
 285 xdefQED@stackthetoks@the@temptokena%
 286 
 287 newcommandpopQED%
 288 begingroupletqed@eltpopQED@elt QED@stackrelaxrelaxendgroup
 289 
 290 defpopQED@elt#1#2relax#1gdefQED@stack#2
 291 newcommandqedhere%
 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 pushQEDfoo when the stack is empty. Two scratch token registers are set: first toks@ is set to qed@eltfoo, 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@stackunexpandedqed@elt#1unexpandedexpandafterQED@stack

So now QED@stack will expand to qed@eltfoo. If another pushQEDbar follows, the expansion would become qed@eltbarqed@eltfoo. 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@eltfoorelaxrelax

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

#1 <- foo
#2 <- 

and therefore

foogdefQED@stackrelax

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

#1 <- bar
#2 <- qed@eltfoo

and bargdefQED@stackqed@eltfoorelax 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 newenvironmentproof[1][proofname]par
 433 pushQEDqed%
 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.

documentclassarticle
usepackagexparse

ExplSyntaxOn

NewDocumentCommandnewstackm
 
 seq_new:c g_thorsten_#1_stack_seq 
 

NewDocumentCommandpushmm
 % #1 is the stack's name, #2 the item to push
 seq_gpush:cn g_thorsten_#1_stack_seq #2 
 

NewDocumentCommandpopmo
 % #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

newstackenv

newenvironmentmyEnv[1][default]
 %
 pushenv#1%
 csname x#1endcsname
 
 %
 popenv[csname endx##1endcsname]%
 

newenvironmentxdefaultpar startfinishpar
newenvironmentxinnerpar startinnerfinishinnerpar

begindocument

beginmyEnv
beginmyEnv[inner]
endmyEnv
endmyEnv

newstackfoo

pushfooA
pushfooB
pushfooC

popfoo[@@#1@@]
popfoo[??#1??]
popfoo[!!#1!!]
popfoo[---#1---]

enddocument

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 popfoo[---#1---]