How to reuse a command inside another environment

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
2
down vote

favorite












For my own needs, I am writing a package holding some environments definitions. I also have some commands that I want to be available only inside these environments.
So I define these commands inside the environment definition.



My .sty files looks like this



NeedsTeXFormatLaTeX2e
ProvidesPackagemypackage[version 0.1]
newenvironmentmyenvirA[1]

 newcommandmycommandA[1]
 %
 %... do something
 %
 % here, the "before" part of code 


 % here, the "after" part of code 



newenvironmentmyenvirB[1]

 newcommandmycommandB[1]
 %
 %.. do something
 %





Now, say I want to make mycommandA available inside myenvirB blocs. Sure, I can copy/paste, but that is bad programming (error prone).



Question: Does Latex provide a way to handle this case ?



If not, can I put that command definition in a file and input it? (so I only have to define it once). Will that work once the package is installed in my Latex tree ?



Sorry if unclear, please point me on other question if this appears as a dupe. Couldn't find any, although this one is possibly related (?). But it is unclear to me if the answers apply to my question.






macros packages







share|improve this question



















  • 1




    You can define the command outside the newenvironment with a private name, say, my@internal@command, and in the environment you can do letmycommandmy@internal@command.
    – Phelype Oleinik
    4 hours ago















up vote
2
down vote

favorite












For my own needs, I am writing a package holding some environments definitions. I also have some commands that I want to be available only inside these environments.
So I define these commands inside the environment definition.



My .sty files looks like this



NeedsTeXFormatLaTeX2e
ProvidesPackagemypackage[version 0.1]
newenvironmentmyenvirA[1]

 newcommandmycommandA[1]
 %
 %... do something
 %
 % here, the "before" part of code 


 % here, the "after" part of code 



newenvironmentmyenvirB[1]

 newcommandmycommandB[1]
 %
 %.. do something
 %





Now, say I want to make mycommandA available inside myenvirB blocs. Sure, I can copy/paste, but that is bad programming (error prone).



Question: Does Latex provide a way to handle this case ?



If not, can I put that command definition in a file and input it? (so I only have to define it once). Will that work once the package is installed in my Latex tree ?



Sorry if unclear, please point me on other question if this appears as a dupe. Couldn't find any, although this one is possibly related (?). But it is unclear to me if the answers apply to my question.






macros packages







share|improve this question



















  • 1




    You can define the command outside the newenvironment with a private name, say, my@internal@command, and in the environment you can do letmycommandmy@internal@command.
    – Phelype Oleinik
    4 hours ago













up vote
2
down vote

favorite









up vote
2
down vote

favorite











For my own needs, I am writing a package holding some environments definitions. I also have some commands that I want to be available only inside these environments.
So I define these commands inside the environment definition.



My .sty files looks like this



NeedsTeXFormatLaTeX2e
ProvidesPackagemypackage[version 0.1]
newenvironmentmyenvirA[1]

 newcommandmycommandA[1]
 %
 %... do something
 %
 % here, the "before" part of code 


 % here, the "after" part of code 



newenvironmentmyenvirB[1]

 newcommandmycommandB[1]
 %
 %.. do something
 %





Now, say I want to make mycommandA available inside myenvirB blocs. Sure, I can copy/paste, but that is bad programming (error prone).



Question: Does Latex provide a way to handle this case ?



If not, can I put that command definition in a file and input it? (so I only have to define it once). Will that work once the package is installed in my Latex tree ?



Sorry if unclear, please point me on other question if this appears as a dupe. Couldn't find any, although this one is possibly related (?). But it is unclear to me if the answers apply to my question.






macros packages







share|improve this question















For my own needs, I am writing a package holding some environments definitions. I also have some commands that I want to be available only inside these environments.
So I define these commands inside the environment definition.



My .sty files looks like this



NeedsTeXFormatLaTeX2e
ProvidesPackagemypackage[version 0.1]
newenvironmentmyenvirA[1]

 newcommandmycommandA[1]
 %
 %... do something
 %
 % here, the "before" part of code 


 % here, the "after" part of code 



newenvironmentmyenvirB[1]

 newcommandmycommandB[1]
 %
 %.. do something
 %





Now, say I want to make mycommandA available inside myenvirB blocs. Sure, I can copy/paste, but that is bad programming (error prone).



Question: Does Latex provide a way to handle this case ?



If not, can I put that command definition in a file and input it? (so I only have to define it once). Will that work once the package is installed in my Latex tree ?



Sorry if unclear, please point me on other question if this appears as a dupe. Couldn't find any, although this one is possibly related (?). But it is unclear to me if the answers apply to my question.






macros packages




macros packages






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 20 mins ago

























asked 4 hours ago









kebs

428511




428511







  • 1




    You can define the command outside the newenvironment with a private name, say, my@internal@command, and in the environment you can do letmycommandmy@internal@command.
    – Phelype Oleinik
    4 hours ago













  • 1




    You can define the command outside the newenvironment with a private name, say, my@internal@command, and in the environment you can do letmycommandmy@internal@command.
    – Phelype Oleinik
    4 hours ago








1




1




You can define the command outside the newenvironment with a private name, say, my@internal@command, and in the environment you can do letmycommandmy@internal@command.
– Phelype Oleinik
4 hours ago





You can define the command outside the newenvironment with a private name, say, my@internal@command, and in the environment you can do letmycommandmy@internal@command.
– Phelype Oleinik
4 hours ago











2 Answers
2






active

oldest

votes

















up vote
2
down vote













I guess that the definition of mycommandA in myenvirA (I won't use numbers, which are illegal in command names) depends on the argument passed to the environment, otherwise the problem is easy to solve, by just defining mycommandA directly.



newcommandtemporarycommandname % initialize
newenvironmentmyenvirA[1]
 %
 renewcommandtemporarycommandname[1]something with #1 and ##1%
 globalletmycommandAtemporarycommandname
 % whatever else
 
 %
 % the end part


Now mycommandA is usable everywhere, after beginmyenvirA has been executed. Further calls of myenvirA will change the meaning of mycommandA, of course.






share|improve this answer




















  • Thanks for answer. Oops, yeah, sorry for number, I'll edit question to make it (at least) correct.
    – kebs
    21 mins ago

















up vote
2
down vote













You can't grab a macro definition from another environment where it is defined, since the environment necessarily provides a limited scope for that macro (as it is grouped).



% mycommand does not exist here
beginmyenvironment
 % _Local_ definition of mycommand
 newcommandmycommand<cmd definition>
 % mycommand exists here
 % ...
endmyenvironment
% mycommand does not exist here


Perhaps there are ways to do that, but it's not worth the effort. You should instead define the macro to be globally available, or read it in from an external file via input every time you need it (if properly installed within your installation folder). The latter option would slow down compilation.



The question you have to ask yourself is why you want to have the definition only be available locally to an environment. Do you want to save memory? That would have been a problem a couple of decades ago, but not anymore. Do you think it will provide for a cleaner package? If so, rather define a "namespace" by preceding each macro for your package mypackage by @mypackage@. This way your macros will look like



@mypackage@mycommandA
@mypackage@mycommandB
...


The @ symbol in macros can be used without official declaration of a makeatletter...makeatother pair within a package, making it somewhat hidden to the end user. The idea of a "namespace" or @-macros is fairly common in packages.






share|improve this answer




















  • Thanks for answer. Good point, but having to use @mypackage@mycommandA is a constraint I'd rather avoid.
    – kebs
    16 mins ago










  • "why you want to have the definition only be available locally to an environment": this is because the command only makes sense inside the environment. This environment actually does some Tikz drawing, and the command inside adds some content inside the drawing.
    – kebs
    14 mins ago










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',
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
);



);













 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f458080%2fhow-to-reuse-a-command-inside-another-environment%23new-answer', 'question_page');

);

Post as a guest

















2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
2
down vote













I guess that the definition of mycommandA in myenvirA (I won't use numbers, which are illegal in command names) depends on the argument passed to the environment, otherwise the problem is easy to solve, by just defining mycommandA directly.



newcommandtemporarycommandname % initialize
newenvironmentmyenvirA[1]
 %
 renewcommandtemporarycommandname[1]something with #1 and ##1%
 globalletmycommandAtemporarycommandname
 % whatever else
 
 %
 % the end part


Now mycommandA is usable everywhere, after beginmyenvirA has been executed. Further calls of myenvirA will change the meaning of mycommandA, of course.






share|improve this answer




















  • Thanks for answer. Oops, yeah, sorry for number, I'll edit question to make it (at least) correct.
    – kebs
    21 mins ago














up vote
2
down vote













I guess that the definition of mycommandA in myenvirA (I won't use numbers, which are illegal in command names) depends on the argument passed to the environment, otherwise the problem is easy to solve, by just defining mycommandA directly.



newcommandtemporarycommandname % initialize
newenvironmentmyenvirA[1]
 %
 renewcommandtemporarycommandname[1]something with #1 and ##1%
 globalletmycommandAtemporarycommandname
 % whatever else
 
 %
 % the end part


Now mycommandA is usable everywhere, after beginmyenvirA has been executed. Further calls of myenvirA will change the meaning of mycommandA, of course.






share|improve this answer




















  • Thanks for answer. Oops, yeah, sorry for number, I'll edit question to make it (at least) correct.
    – kebs
    21 mins ago












up vote
2
down vote










up vote
2
down vote









I guess that the definition of mycommandA in myenvirA (I won't use numbers, which are illegal in command names) depends on the argument passed to the environment, otherwise the problem is easy to solve, by just defining mycommandA directly.



newcommandtemporarycommandname % initialize
newenvironmentmyenvirA[1]
 %
 renewcommandtemporarycommandname[1]something with #1 and ##1%
 globalletmycommandAtemporarycommandname
 % whatever else
 
 %
 % the end part


Now mycommandA is usable everywhere, after beginmyenvirA has been executed. Further calls of myenvirA will change the meaning of mycommandA, of course.






share|improve this answer












I guess that the definition of mycommandA in myenvirA (I won't use numbers, which are illegal in command names) depends on the argument passed to the environment, otherwise the problem is easy to solve, by just defining mycommandA directly.



newcommandtemporarycommandname % initialize
newenvironmentmyenvirA[1]
 %
 renewcommandtemporarycommandname[1]something with #1 and ##1%
 globalletmycommandAtemporarycommandname
 % whatever else
 
 %
 % the end part


Now mycommandA is usable everywhere, after beginmyenvirA has been executed. Further calls of myenvirA will change the meaning of mycommandA, of course.







share|improve this answer












share|improve this answer



share|improve this answer










answered 4 hours ago









egreg

694k8518443099




694k8518443099











  • Thanks for answer. Oops, yeah, sorry for number, I'll edit question to make it (at least) correct.
    – kebs
    21 mins ago
















  • Thanks for answer. Oops, yeah, sorry for number, I'll edit question to make it (at least) correct.
    – kebs
    21 mins ago















Thanks for answer. Oops, yeah, sorry for number, I'll edit question to make it (at least) correct.
– kebs
21 mins ago




Thanks for answer. Oops, yeah, sorry for number, I'll edit question to make it (at least) correct.
– kebs
21 mins ago










up vote
2
down vote













You can't grab a macro definition from another environment where it is defined, since the environment necessarily provides a limited scope for that macro (as it is grouped).



% mycommand does not exist here
beginmyenvironment
 % _Local_ definition of mycommand
 newcommandmycommand<cmd definition>
 % mycommand exists here
 % ...
endmyenvironment
% mycommand does not exist here


Perhaps there are ways to do that, but it's not worth the effort. You should instead define the macro to be globally available, or read it in from an external file via input every time you need it (if properly installed within your installation folder). The latter option would slow down compilation.



The question you have to ask yourself is why you want to have the definition only be available locally to an environment. Do you want to save memory? That would have been a problem a couple of decades ago, but not anymore. Do you think it will provide for a cleaner package? If so, rather define a "namespace" by preceding each macro for your package mypackage by @mypackage@. This way your macros will look like



@mypackage@mycommandA
@mypackage@mycommandB
...


The @ symbol in macros can be used without official declaration of a makeatletter...makeatother pair within a package, making it somewhat hidden to the end user. The idea of a "namespace" or @-macros is fairly common in packages.






share|improve this answer




















  • Thanks for answer. Good point, but having to use @mypackage@mycommandA is a constraint I'd rather avoid.
    – kebs
    16 mins ago










  • "why you want to have the definition only be available locally to an environment": this is because the command only makes sense inside the environment. This environment actually does some Tikz drawing, and the command inside adds some content inside the drawing.
    – kebs
    14 mins ago














up vote
2
down vote













You can't grab a macro definition from another environment where it is defined, since the environment necessarily provides a limited scope for that macro (as it is grouped).



% mycommand does not exist here
beginmyenvironment
 % _Local_ definition of mycommand
 newcommandmycommand<cmd definition>
 % mycommand exists here
 % ...
endmyenvironment
% mycommand does not exist here


Perhaps there are ways to do that, but it's not worth the effort. You should instead define the macro to be globally available, or read it in from an external file via input every time you need it (if properly installed within your installation folder). The latter option would slow down compilation.



The question you have to ask yourself is why you want to have the definition only be available locally to an environment. Do you want to save memory? That would have been a problem a couple of decades ago, but not anymore. Do you think it will provide for a cleaner package? If so, rather define a "namespace" by preceding each macro for your package mypackage by @mypackage@. This way your macros will look like



@mypackage@mycommandA
@mypackage@mycommandB
...


The @ symbol in macros can be used without official declaration of a makeatletter...makeatother pair within a package, making it somewhat hidden to the end user. The idea of a "namespace" or @-macros is fairly common in packages.






share|improve this answer




















  • Thanks for answer. Good point, but having to use @mypackage@mycommandA is a constraint I'd rather avoid.
    – kebs
    16 mins ago










  • "why you want to have the definition only be available locally to an environment": this is because the command only makes sense inside the environment. This environment actually does some Tikz drawing, and the command inside adds some content inside the drawing.
    – kebs
    14 mins ago












up vote
2
down vote










up vote
2
down vote









You can't grab a macro definition from another environment where it is defined, since the environment necessarily provides a limited scope for that macro (as it is grouped).



% mycommand does not exist here
beginmyenvironment
 % _Local_ definition of mycommand
 newcommandmycommand<cmd definition>
 % mycommand exists here
 % ...
endmyenvironment
% mycommand does not exist here


Perhaps there are ways to do that, but it's not worth the effort. You should instead define the macro to be globally available, or read it in from an external file via input every time you need it (if properly installed within your installation folder). The latter option would slow down compilation.



The question you have to ask yourself is why you want to have the definition only be available locally to an environment. Do you want to save memory? That would have been a problem a couple of decades ago, but not anymore. Do you think it will provide for a cleaner package? If so, rather define a "namespace" by preceding each macro for your package mypackage by @mypackage@. This way your macros will look like



@mypackage@mycommandA
@mypackage@mycommandB
...


The @ symbol in macros can be used without official declaration of a makeatletter...makeatother pair within a package, making it somewhat hidden to the end user. The idea of a "namespace" or @-macros is fairly common in packages.






share|improve this answer












You can't grab a macro definition from another environment where it is defined, since the environment necessarily provides a limited scope for that macro (as it is grouped).



% mycommand does not exist here
beginmyenvironment
 % _Local_ definition of mycommand
 newcommandmycommand<cmd definition>
 % mycommand exists here
 % ...
endmyenvironment
% mycommand does not exist here


Perhaps there are ways to do that, but it's not worth the effort. You should instead define the macro to be globally available, or read it in from an external file via input every time you need it (if properly installed within your installation folder). The latter option would slow down compilation.



The question you have to ask yourself is why you want to have the definition only be available locally to an environment. Do you want to save memory? That would have been a problem a couple of decades ago, but not anymore. Do you think it will provide for a cleaner package? If so, rather define a "namespace" by preceding each macro for your package mypackage by @mypackage@. This way your macros will look like



@mypackage@mycommandA
@mypackage@mycommandB
...


The @ symbol in macros can be used without official declaration of a makeatletter...makeatother pair within a package, making it somewhat hidden to the end user. The idea of a "namespace" or @-macros is fairly common in packages.







share|improve this answer












share|improve this answer



share|improve this answer










answered 4 hours ago









Werner

427k589371611




427k589371611











  • Thanks for answer. Good point, but having to use @mypackage@mycommandA is a constraint I'd rather avoid.
    – kebs
    16 mins ago










  • "why you want to have the definition only be available locally to an environment": this is because the command only makes sense inside the environment. This environment actually does some Tikz drawing, and the command inside adds some content inside the drawing.
    – kebs
    14 mins ago
















  • Thanks for answer. Good point, but having to use @mypackage@mycommandA is a constraint I'd rather avoid.
    – kebs
    16 mins ago










  • "why you want to have the definition only be available locally to an environment": this is because the command only makes sense inside the environment. This environment actually does some Tikz drawing, and the command inside adds some content inside the drawing.
    – kebs
    14 mins ago















Thanks for answer. Good point, but having to use @mypackage@mycommandA is a constraint I'd rather avoid.
– kebs
16 mins ago




Thanks for answer. Good point, but having to use @mypackage@mycommandA is a constraint I'd rather avoid.
– kebs
16 mins ago












"why you want to have the definition only be available locally to an environment": this is because the command only makes sense inside the environment. This environment actually does some Tikz drawing, and the command inside adds some content inside the drawing.
– kebs
14 mins ago




"why you want to have the definition only be available locally to an environment": this is because the command only makes sense inside the environment. This environment actually does some Tikz drawing, and the command inside adds some content inside the drawing.
– kebs
14 mins ago

















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f458080%2fhow-to-reuse-a-command-inside-another-environment%23new-answer', 'question_page');

);

Post as a guest
































































Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being “babysat” by supervisor

Image
Clash Royale CLAN TAG #URR8PPP .everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0; up vote 31 down vote favorite 4 I hold a PhD in mechanical engineering with a 7 year background in self-guided, self-paced research including 2 years as a graduate level course instructor and a subject matter expert for various engineering projects in a university setting in the United States. For the last 10-11 months, I am working in a research industry in France where my task is to debug C++ spaghetti code written over a period of several years by my current supervisor. It is a team of 2: just I and my supervisor. Diurnally, I am posed with a "bug of the day" to get out of this C++ code. My supervisor generally gives me about 15-30 minutes to solve it and then accosts me about whether or not the task is completed and then rinses and repeats this until the end of the day. Off-late, my supervisor has been holding 6-7 hour long "meetin
Read more

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Image
Clash Royale CLAN TAG #URR8PPP up vote 2 down vote favorite Many fantasy worlds have multiple humanoid species (elves, orcs, humans, etc) living in the same world, in addition to that, they often have the ability to interbreed. And I can't help but question their believability... fantasy-races reproduction interspecies-relations share | improve this question edited Aug 9 at 14:46 Michael Kjörling ♦ 21.1k 10 85 161 asked Aug 9 at 13:13 Chlodio 118 6 closed as unclear what you're asking by MichaelK, Gryphon, John, Vincent, Frostfyre Aug 9 at 15:25 Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question. 3 Stack Exchange exist to
Read more

Confectionery

Image
Prepared foods made with a lot of sugar or other cabohydrates "Sweetmeat" redirects here. For the racehorse, see Sweetmeat (horse). Not to be confused with Sweetbread. This Kransekake is a traditional Scandinavian baker's confection. Confectionery is the art of making confections , which are food items that are rich in sugar and carbohydrates. Exact definitions are difficult. [1] In general, though, confectionery is divided into two broad and somewhat overlapping categories, bakers' confections and sugar confections. [2] Bakers' confectionery, also called flour confections , includes principally sweet pastries, cakes, and similar baked goods. Sugar confectionery includes candies ( sweets in British English), candied nuts, chocolates, chewing gum, bubble gum, pastillage, and other confections that are made primarily of sugar. In some cases, chocolate confections (confections made of chocolate) are treated as a separate category, as are sugar-free versions of
Read more