pgfkeys: .store in constructed macroWhy isn't everything expandable?Appending to a style that sets code with arguments in pgfkeyspgfkeys: Store unknown keys in a commandProblem with pgf library in TexLiveModify `funcdef` macro to use `pgfkeys` instead of `keyval`Difference between pgfkeys that use .estore and .store for subscriptspgfkeys - why .store and pgfkeysvalueof are different?Store coordinate tuple in pgfkeysStoring options for pgfkeys inside macroUsing macros in pgfkeys command
What exactly makes a General Products hull nearly indestructible?
What do I do when a student working in my lab "ghosts" me?
Is the apartment I want to rent a scam?
What is "ass door"?
How can I stop myself from micromanaging other PCs' actions?
Is Grandpa Irrational? Another Grandpa Mystery
Strange Cron Job takes up 100% of CPU Ubuntu 18 LTS Server
Should I leave my PhD after 3 years with a Masters?
Terence Tao - type books in other fields?
Would it be a good idea to memorize relative interval positions on guitar?
401(k) investment after being fired. Do I own it?
Are gangsters hired to attack people at a train station classified as a terrorist attack?
Why did NASA use U.S customary units?
Invert Some Switches on a Switchboard
Hold[Expression] (or similar) in InputField that truly holds the input unmodified
Using "Kollege" as "university friend"?
Do I need another Schengen Visa
Inadvertently nuked my disk permission structure - why?
Monty Hall Problem with a Fallible Monty
Is it normal practice to screen share with a client?
What was the rationale behind 36 bit computer architectures?
Keeping an "hot eyeball planet" wet
Explanation for a joke about a three-legged dog that walks into a bar
Where is this photo of a group of hikers taken? Is it really in the Ural?
pgfkeys: .store in constructed macro
Why isn't everything expandable?Appending to a style that sets code with arguments in pgfkeyspgfkeys: Store unknown keys in a commandProblem with pgf library in TexLiveModify `funcdef` macro to use `pgfkeys` instead of `keyval`Difference between pgfkeys that use .estore and .store for subscriptspgfkeys - why .store and pgfkeysvalueof are different?Store coordinate tuple in pgfkeysStoring options for pgfkeys inside macroUsing macros in pgfkeys command
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
I'm trying to store a value in a macro that is constructed from the arguments of another macro, but I must be missing something because the macro is not created.
MWE:
documentclassarticle
RequirePackagepgfkeys
newcommandzkeys[1]pgfkeys/prefix/.cd,#1
newcommandzsetup[2]
zkeys
#1/.store in=z#2,
zsetupkeyastoragea
zsetupkeybstorageb
zkeys
keya=test,
begindocument
zstoragea % Undefined control sequence.
enddocument
expansion pgfkeys
add a comment |
I'm trying to store a value in a macro that is constructed from the arguments of another macro, but I must be missing something because the macro is not created.
MWE:
documentclassarticle
RequirePackagepgfkeys
newcommandzkeys[1]pgfkeys/prefix/.cd,#1
newcommandzsetup[2]
zkeys
#1/.store in=z#2,
zsetupkeyastoragea
zsetupkeybstorageb
zkeys
keya=test,
begindocument
zstoragea % Undefined control sequence.
enddocument
expansion pgfkeys
add a comment |
I'm trying to store a value in a macro that is constructed from the arguments of another macro, but I must be missing something because the macro is not created.
MWE:
documentclassarticle
RequirePackagepgfkeys
newcommandzkeys[1]pgfkeys/prefix/.cd,#1
newcommandzsetup[2]
zkeys
#1/.store in=z#2,
zsetupkeyastoragea
zsetupkeybstorageb
zkeys
keya=test,
begindocument
zstoragea % Undefined control sequence.
enddocument
expansion pgfkeys
I'm trying to store a value in a macro that is constructed from the arguments of another macro, but I must be missing something because the macro is not created.
MWE:
documentclassarticle
RequirePackagepgfkeys
newcommandzkeys[1]pgfkeys/prefix/.cd,#1
newcommandzsetup[2]
zkeys
#1/.store in=z#2,
zsetupkeyastoragea
zsetupkeybstorageb
zkeys
keya=test,
begindocument
zstoragea % Undefined control sequence.
enddocument
expansion pgfkeys
expansion pgfkeys
asked Jul 15 at 19:09
meidemeide
4372 silver badges9 bronze badges
4372 silver badges9 bronze badges
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
New solution
Another, more flexible approach is to extend the handlers pgfkeys
accepts by a new one .store in cs
which does basically the same as .store in
, but doesn't take a complete control sequence name as value but a list of characters from that the final control sequence is built. So the following calls would be equal:
foo/.store in=mymacro
foo/.store in cs=mymacro
The full example then looks like
documentclassarticle
RequirePackagepgfkeys
newcommandzkeys[1]pgfkeys/prefix/.cd,#1
pgfkeys/handlers/.store in cs/.code=pgfkeysalso%
pgfkeyscurrentpath/.code=expandafterdefcsname#1endcsname##1%
newcommandzsetup[2]%
zkeys
#1/.store in cs=z#2,
%
zsetupkeyastoragea
zsetupkeybstorageb
zkeys
keya=test,
begindocument
zstoragea % Undefined control sequence.
enddocument
Old solution
When you type z#2
, TeX parses this as the command name z
followed by the tokens inserted from the second argument. If you want to build a new control sequence from a series of characters/tokens, you have to use the sequence csname ...endcsname
, where ...
would be z#2
in this case.
However, in this specific situation store in=csname z#2endcsname
wouldn't work, because the csname
call must be expanded exactly once to build the actual new control sequence from the characters, but not more than once, otherwise the built macro would be tried to expanded itself.
A possible solution is to wrap the whole key definitions into an edef
, prefix all commands in it by noexpand
, and use unexpandedexpandafter...
in each place, we want exactly one expansion step:
newcommandzsetup[2]
edeftemp%
noexpandzkeys
#1/.store in=unexpandedexpandaftercsname z#2endcsname,
%
temp
zstoragea
will then expand to test
.
1
Aha, I forgot to mention that I had triedcsname
without success, thanks for the thorough explanation on why that didn't work!
– meide
Jul 16 at 4:04
add a comment |
Here are two solutions. They both take care not to expand the first argument of zsetup
before passing it to zkeys
, nor to define or overwrite any macro in the current group as a side effect.
First solution
documentclassarticle
usepackagepgfkeys
newcommandzkeys[1]pgfkeys/prefix/.cd,#1
newcommand*zsetup[2]%
begingroup
edefargunexpanded#1/.store in=%
expandafternoexpandcsname z#2endcsname%
expandafter
endgroup
expandafterzkeysexpandafterarg%
zsetupkeyastoragea
zsetupkeybstorageb
zkeys
keya=test,
begindocument
zstoragea % Print 'test'
enddocument
Second solution
Same code, except for the definition of zsetup
:
newcommand*zsetup[2]%
begingroup
deftmp##1zkeys#1/.store in=##1%
expandafterexpandafterexpandafter
endgroup
expandaftertmpcsname z#2endcsname
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "85"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f500098%2fpgfkeys-store-in-constructed-macro%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
New solution
Another, more flexible approach is to extend the handlers pgfkeys
accepts by a new one .store in cs
which does basically the same as .store in
, but doesn't take a complete control sequence name as value but a list of characters from that the final control sequence is built. So the following calls would be equal:
foo/.store in=mymacro
foo/.store in cs=mymacro
The full example then looks like
documentclassarticle
RequirePackagepgfkeys
newcommandzkeys[1]pgfkeys/prefix/.cd,#1
pgfkeys/handlers/.store in cs/.code=pgfkeysalso%
pgfkeyscurrentpath/.code=expandafterdefcsname#1endcsname##1%
newcommandzsetup[2]%
zkeys
#1/.store in cs=z#2,
%
zsetupkeyastoragea
zsetupkeybstorageb
zkeys
keya=test,
begindocument
zstoragea % Undefined control sequence.
enddocument
Old solution
When you type z#2
, TeX parses this as the command name z
followed by the tokens inserted from the second argument. If you want to build a new control sequence from a series of characters/tokens, you have to use the sequence csname ...endcsname
, where ...
would be z#2
in this case.
However, in this specific situation store in=csname z#2endcsname
wouldn't work, because the csname
call must be expanded exactly once to build the actual new control sequence from the characters, but not more than once, otherwise the built macro would be tried to expanded itself.
A possible solution is to wrap the whole key definitions into an edef
, prefix all commands in it by noexpand
, and use unexpandedexpandafter...
in each place, we want exactly one expansion step:
newcommandzsetup[2]
edeftemp%
noexpandzkeys
#1/.store in=unexpandedexpandaftercsname z#2endcsname,
%
temp
zstoragea
will then expand to test
.
1
Aha, I forgot to mention that I had triedcsname
without success, thanks for the thorough explanation on why that didn't work!
– meide
Jul 16 at 4:04
add a comment |
New solution
Another, more flexible approach is to extend the handlers pgfkeys
accepts by a new one .store in cs
which does basically the same as .store in
, but doesn't take a complete control sequence name as value but a list of characters from that the final control sequence is built. So the following calls would be equal:
foo/.store in=mymacro
foo/.store in cs=mymacro
The full example then looks like
documentclassarticle
RequirePackagepgfkeys
newcommandzkeys[1]pgfkeys/prefix/.cd,#1
pgfkeys/handlers/.store in cs/.code=pgfkeysalso%
pgfkeyscurrentpath/.code=expandafterdefcsname#1endcsname##1%
newcommandzsetup[2]%
zkeys
#1/.store in cs=z#2,
%
zsetupkeyastoragea
zsetupkeybstorageb
zkeys
keya=test,
begindocument
zstoragea % Undefined control sequence.
enddocument
Old solution
When you type z#2
, TeX parses this as the command name z
followed by the tokens inserted from the second argument. If you want to build a new control sequence from a series of characters/tokens, you have to use the sequence csname ...endcsname
, where ...
would be z#2
in this case.
However, in this specific situation store in=csname z#2endcsname
wouldn't work, because the csname
call must be expanded exactly once to build the actual new control sequence from the characters, but not more than once, otherwise the built macro would be tried to expanded itself.
A possible solution is to wrap the whole key definitions into an edef
, prefix all commands in it by noexpand
, and use unexpandedexpandafter...
in each place, we want exactly one expansion step:
newcommandzsetup[2]
edeftemp%
noexpandzkeys
#1/.store in=unexpandedexpandaftercsname z#2endcsname,
%
temp
zstoragea
will then expand to test
.
1
Aha, I forgot to mention that I had triedcsname
without success, thanks for the thorough explanation on why that didn't work!
– meide
Jul 16 at 4:04
add a comment |
New solution
Another, more flexible approach is to extend the handlers pgfkeys
accepts by a new one .store in cs
which does basically the same as .store in
, but doesn't take a complete control sequence name as value but a list of characters from that the final control sequence is built. So the following calls would be equal:
foo/.store in=mymacro
foo/.store in cs=mymacro
The full example then looks like
documentclassarticle
RequirePackagepgfkeys
newcommandzkeys[1]pgfkeys/prefix/.cd,#1
pgfkeys/handlers/.store in cs/.code=pgfkeysalso%
pgfkeyscurrentpath/.code=expandafterdefcsname#1endcsname##1%
newcommandzsetup[2]%
zkeys
#1/.store in cs=z#2,
%
zsetupkeyastoragea
zsetupkeybstorageb
zkeys
keya=test,
begindocument
zstoragea % Undefined control sequence.
enddocument
Old solution
When you type z#2
, TeX parses this as the command name z
followed by the tokens inserted from the second argument. If you want to build a new control sequence from a series of characters/tokens, you have to use the sequence csname ...endcsname
, where ...
would be z#2
in this case.
However, in this specific situation store in=csname z#2endcsname
wouldn't work, because the csname
call must be expanded exactly once to build the actual new control sequence from the characters, but not more than once, otherwise the built macro would be tried to expanded itself.
A possible solution is to wrap the whole key definitions into an edef
, prefix all commands in it by noexpand
, and use unexpandedexpandafter...
in each place, we want exactly one expansion step:
newcommandzsetup[2]
edeftemp%
noexpandzkeys
#1/.store in=unexpandedexpandaftercsname z#2endcsname,
%
temp
zstoragea
will then expand to test
.
New solution
Another, more flexible approach is to extend the handlers pgfkeys
accepts by a new one .store in cs
which does basically the same as .store in
, but doesn't take a complete control sequence name as value but a list of characters from that the final control sequence is built. So the following calls would be equal:
foo/.store in=mymacro
foo/.store in cs=mymacro
The full example then looks like
documentclassarticle
RequirePackagepgfkeys
newcommandzkeys[1]pgfkeys/prefix/.cd,#1
pgfkeys/handlers/.store in cs/.code=pgfkeysalso%
pgfkeyscurrentpath/.code=expandafterdefcsname#1endcsname##1%
newcommandzsetup[2]%
zkeys
#1/.store in cs=z#2,
%
zsetupkeyastoragea
zsetupkeybstorageb
zkeys
keya=test,
begindocument
zstoragea % Undefined control sequence.
enddocument
Old solution
When you type z#2
, TeX parses this as the command name z
followed by the tokens inserted from the second argument. If you want to build a new control sequence from a series of characters/tokens, you have to use the sequence csname ...endcsname
, where ...
would be z#2
in this case.
However, in this specific situation store in=csname z#2endcsname
wouldn't work, because the csname
call must be expanded exactly once to build the actual new control sequence from the characters, but not more than once, otherwise the built macro would be tried to expanded itself.
A possible solution is to wrap the whole key definitions into an edef
, prefix all commands in it by noexpand
, and use unexpandedexpandafter...
in each place, we want exactly one expansion step:
newcommandzsetup[2]
edeftemp%
noexpandzkeys
#1/.store in=unexpandedexpandaftercsname z#2endcsname,
%
temp
zstoragea
will then expand to test
.
edited Jul 15 at 20:59
answered Jul 15 at 20:26
siracusasiracusa
7,4142 gold badges18 silver badges34 bronze badges
7,4142 gold badges18 silver badges34 bronze badges
1
Aha, I forgot to mention that I had triedcsname
without success, thanks for the thorough explanation on why that didn't work!
– meide
Jul 16 at 4:04
add a comment |
1
Aha, I forgot to mention that I had triedcsname
without success, thanks for the thorough explanation on why that didn't work!
– meide
Jul 16 at 4:04
1
1
Aha, I forgot to mention that I had tried
csname
without success, thanks for the thorough explanation on why that didn't work!– meide
Jul 16 at 4:04
Aha, I forgot to mention that I had tried
csname
without success, thanks for the thorough explanation on why that didn't work!– meide
Jul 16 at 4:04
add a comment |
Here are two solutions. They both take care not to expand the first argument of zsetup
before passing it to zkeys
, nor to define or overwrite any macro in the current group as a side effect.
First solution
documentclassarticle
usepackagepgfkeys
newcommandzkeys[1]pgfkeys/prefix/.cd,#1
newcommand*zsetup[2]%
begingroup
edefargunexpanded#1/.store in=%
expandafternoexpandcsname z#2endcsname%
expandafter
endgroup
expandafterzkeysexpandafterarg%
zsetupkeyastoragea
zsetupkeybstorageb
zkeys
keya=test,
begindocument
zstoragea % Print 'test'
enddocument
Second solution
Same code, except for the definition of zsetup
:
newcommand*zsetup[2]%
begingroup
deftmp##1zkeys#1/.store in=##1%
expandafterexpandafterexpandafter
endgroup
expandaftertmpcsname z#2endcsname
add a comment |
Here are two solutions. They both take care not to expand the first argument of zsetup
before passing it to zkeys
, nor to define or overwrite any macro in the current group as a side effect.
First solution
documentclassarticle
usepackagepgfkeys
newcommandzkeys[1]pgfkeys/prefix/.cd,#1
newcommand*zsetup[2]%
begingroup
edefargunexpanded#1/.store in=%
expandafternoexpandcsname z#2endcsname%
expandafter
endgroup
expandafterzkeysexpandafterarg%
zsetupkeyastoragea
zsetupkeybstorageb
zkeys
keya=test,
begindocument
zstoragea % Print 'test'
enddocument
Second solution
Same code, except for the definition of zsetup
:
newcommand*zsetup[2]%
begingroup
deftmp##1zkeys#1/.store in=##1%
expandafterexpandafterexpandafter
endgroup
expandaftertmpcsname z#2endcsname
add a comment |
Here are two solutions. They both take care not to expand the first argument of zsetup
before passing it to zkeys
, nor to define or overwrite any macro in the current group as a side effect.
First solution
documentclassarticle
usepackagepgfkeys
newcommandzkeys[1]pgfkeys/prefix/.cd,#1
newcommand*zsetup[2]%
begingroup
edefargunexpanded#1/.store in=%
expandafternoexpandcsname z#2endcsname%
expandafter
endgroup
expandafterzkeysexpandafterarg%
zsetupkeyastoragea
zsetupkeybstorageb
zkeys
keya=test,
begindocument
zstoragea % Print 'test'
enddocument
Second solution
Same code, except for the definition of zsetup
:
newcommand*zsetup[2]%
begingroup
deftmp##1zkeys#1/.store in=##1%
expandafterexpandafterexpandafter
endgroup
expandaftertmpcsname z#2endcsname
Here are two solutions. They both take care not to expand the first argument of zsetup
before passing it to zkeys
, nor to define or overwrite any macro in the current group as a side effect.
First solution
documentclassarticle
usepackagepgfkeys
newcommandzkeys[1]pgfkeys/prefix/.cd,#1
newcommand*zsetup[2]%
begingroup
edefargunexpanded#1/.store in=%
expandafternoexpandcsname z#2endcsname%
expandafter
endgroup
expandafterzkeysexpandafterarg%
zsetupkeyastoragea
zsetupkeybstorageb
zkeys
keya=test,
begindocument
zstoragea % Print 'test'
enddocument
Second solution
Same code, except for the definition of zsetup
:
newcommand*zsetup[2]%
begingroup
deftmp##1zkeys#1/.store in=##1%
expandafterexpandafterexpandafter
endgroup
expandaftertmpcsname z#2endcsname
edited Jul 15 at 21:14
answered Jul 15 at 20:48
frougonfrougon
5,6001 gold badge10 silver badges20 bronze badges
5,6001 gold badge10 silver badges20 bronze badges
add a comment |
add a comment |
Thanks for contributing an answer to TeX - LaTeX Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f500098%2fpgfkeys-store-in-constructed-macro%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown