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.










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.










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.










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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 2 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
    4 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




















    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
      4 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
      4 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
      4 mins ago
















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















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




    Thanks for answer. Oops, yeah, sorry for number, I'll edit question to make it (at least) correct.
    – kebs
    4 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
























      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






















        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 3 hours ago









        Werner

        427k589371611




        427k589371611



























             

            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













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Bahrain

            Postfix configuration issue with fips on centos 7; mailgun relay