listings: how to colorize strings between angle brackets












3















I'd like to colorize the names of header files included in angle brackets (<>) in my C examples formatted by the listings package. In the MWE I'd like <brackets.h> to be orange too like "quotes.h". I don't want to do that manually with escapes in every listing but globally. I have tried various crude things including the use of keywordcommentsemicolon (which did not work at all because it is an undefined key although it is mentioned in the documentation... does it need to be enabled?). The most promising results were achieved by using morecomment=[s]{<}{>}. However, that would colorize everything following a <... which is not that uncommon in C ;)
The solution should work independently from the documentclass, especially beamer should work, and preferably work with common listings options (i.e., not change the behavior of other formatting options such as identifierstyle.



documentclass{article}
usepackage[utf8]{inputenc}
usepackage[T1]{fontenc}

usepackage{xcolor}
definecolor{darkorange}{HTML}{C87B0F}

usepackage{listings}
lstset{language=C,captionpos=b}
lstloadlanguages{C}

lstset{%
stringstyle=color{darkorange},
identifierstyle={color{blue}}.
}

begin{document}

begin{lstlisting}[gobble=4]
#include <stdlib.h>
#include "quotes.h"

int main(int argc, char **argv) {

if (argc <= 3)
return 0 > **argv;
return EXIT_SUCCESS;
}
end{lstlisting}

end{document}









share|improve this question





























    3















    I'd like to colorize the names of header files included in angle brackets (<>) in my C examples formatted by the listings package. In the MWE I'd like <brackets.h> to be orange too like "quotes.h". I don't want to do that manually with escapes in every listing but globally. I have tried various crude things including the use of keywordcommentsemicolon (which did not work at all because it is an undefined key although it is mentioned in the documentation... does it need to be enabled?). The most promising results were achieved by using morecomment=[s]{<}{>}. However, that would colorize everything following a <... which is not that uncommon in C ;)
    The solution should work independently from the documentclass, especially beamer should work, and preferably work with common listings options (i.e., not change the behavior of other formatting options such as identifierstyle.



    documentclass{article}
    usepackage[utf8]{inputenc}
    usepackage[T1]{fontenc}

    usepackage{xcolor}
    definecolor{darkorange}{HTML}{C87B0F}

    usepackage{listings}
    lstset{language=C,captionpos=b}
    lstloadlanguages{C}

    lstset{%
    stringstyle=color{darkorange},
    identifierstyle={color{blue}}.
    }

    begin{document}

    begin{lstlisting}[gobble=4]
    #include <stdlib.h>
    #include "quotes.h"

    int main(int argc, char **argv) {

    if (argc <= 3)
    return 0 > **argv;
    return EXIT_SUCCESS;
    }
    end{lstlisting}

    end{document}









    share|improve this question



























      3












      3








      3


      0






      I'd like to colorize the names of header files included in angle brackets (<>) in my C examples formatted by the listings package. In the MWE I'd like <brackets.h> to be orange too like "quotes.h". I don't want to do that manually with escapes in every listing but globally. I have tried various crude things including the use of keywordcommentsemicolon (which did not work at all because it is an undefined key although it is mentioned in the documentation... does it need to be enabled?). The most promising results were achieved by using morecomment=[s]{<}{>}. However, that would colorize everything following a <... which is not that uncommon in C ;)
      The solution should work independently from the documentclass, especially beamer should work, and preferably work with common listings options (i.e., not change the behavior of other formatting options such as identifierstyle.



      documentclass{article}
      usepackage[utf8]{inputenc}
      usepackage[T1]{fontenc}

      usepackage{xcolor}
      definecolor{darkorange}{HTML}{C87B0F}

      usepackage{listings}
      lstset{language=C,captionpos=b}
      lstloadlanguages{C}

      lstset{%
      stringstyle=color{darkorange},
      identifierstyle={color{blue}}.
      }

      begin{document}

      begin{lstlisting}[gobble=4]
      #include <stdlib.h>
      #include "quotes.h"

      int main(int argc, char **argv) {

      if (argc <= 3)
      return 0 > **argv;
      return EXIT_SUCCESS;
      }
      end{lstlisting}

      end{document}









      share|improve this question
















      I'd like to colorize the names of header files included in angle brackets (<>) in my C examples formatted by the listings package. In the MWE I'd like <brackets.h> to be orange too like "quotes.h". I don't want to do that manually with escapes in every listing but globally. I have tried various crude things including the use of keywordcommentsemicolon (which did not work at all because it is an undefined key although it is mentioned in the documentation... does it need to be enabled?). The most promising results were achieved by using morecomment=[s]{<}{>}. However, that would colorize everything following a <... which is not that uncommon in C ;)
      The solution should work independently from the documentclass, especially beamer should work, and preferably work with common listings options (i.e., not change the behavior of other formatting options such as identifierstyle.



      documentclass{article}
      usepackage[utf8]{inputenc}
      usepackage[T1]{fontenc}

      usepackage{xcolor}
      definecolor{darkorange}{HTML}{C87B0F}

      usepackage{listings}
      lstset{language=C,captionpos=b}
      lstloadlanguages{C}

      lstset{%
      stringstyle=color{darkorange},
      identifierstyle={color{blue}}.
      }

      begin{document}

      begin{lstlisting}[gobble=4]
      #include <stdlib.h>
      #include "quotes.h"

      int main(int argc, char **argv) {

      if (argc <= 3)
      return 0 > **argv;
      return EXIT_SUCCESS;
      }
      end{lstlisting}

      end{document}






      listings






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Aug 1 '18 at 14:28







      stefanct

















      asked Jan 11 '18 at 12:38









      stefanctstefanct

      334210




      334210






















          1 Answer
          1






          active

          oldest

          votes


















          4














          Note: I'm making the assumption that the only angle-bracket strings you want colored are those that appear in lines containing a #. If there are other cases, I think my answer can be adapted.





          (The code is below. You can skip the explanations if you like.)



          You can't tell listings which of the strings starting with < should be colored and which shouldn't. But you can circumvent that using basic conditionals.



          You started in the right direction. Let's use a delimiter on <>:



          moredelim=[s][coloroncondition]<>


          with coloroncondition a custom macro giving a new color depending on a custom condition ifcoloranglebrackets:



          newcommandcoloroncondition{ifcoloranglebracketscolor{darkorange}fi}


          If we assume we want to color brackets in lines containing a #, then we can set the condition to true in these particular lines thanks to a delimiter on #:



          moredelim=**[l][coloranglebracketstrue]#


          The ** makes listings cumulate the "style" of that delimiter and any delimiter inside, thus the style for angle-bracket strings whithin lines containing a # will be {coloranglebracketstruecoloroncondition} (which will be ultimately sort of expanded to color{darkorange}), while the style for any other angle-bracket string will be {coloroncondition} (which will be expanded to nothing).





          Working example



          documentclass{article}
          usepackage[utf8]{inputenc}
          usepackage[T1]{fontenc}

          usepackage{xcolor}
          definecolor{darkorange}{HTML}{C87B0F}

          usepackage{listings}
          lstset{language=C,captionpos=b}
          lstloadlanguages{C}

          newififcoloranglebrackets
          coloranglebracketsfalse
          newcommandcoloroncondition{ifcoloranglebracketscolor{darkorange}fi}

          lstset{%
          stringstyle=color{darkorange},
          moredelim=**[directive][coloranglebracketstrue]#,
          moredelim=**[s][coloroncondition]<>
          }

          begin{document}

          begin{lstlisting}[gobble=4]
          #include <brackets.h>
          #include "quotes.h"
          std::cout<<text
          if a < b ...
          end{lstlisting}

          end{document}


          Output:



          colored C code





          About the directive option



          I replaced l by directive when matching the # delimiter. That option is not clearly documented, but I found it in listings source code. Apparently, LaTeX uses it to emphasize keywords starting with a # in C (#include, etc.). l can be used instead, but that would erase the default behavior on such keywords (which is, in this case, to put them in bold font).






          share|improve this answer


























          • Absolutely awesome, thank you! I'll forward a link to the current maintainer... maybe he wanna do something about the formatting itself or the documentation of directive

            – stefanct
            Jan 22 '18 at 13:21











          • However, the solution quickly breaks in most real-world cases where an identifier style is used, e.g., identifierstyle={color{blue}} (at least with the texlive version I am using right now. The first < stops highlighting of identifiers. :(

            – stefanct
            Jul 31 '18 at 18:25











          • @stefanct You're right, I didn't take identifierstyle into consideration. I can't find a fix right now. I suggest you to either 1- un-accept my answer and edit your question with a MWE that includes identifierstyle, or 2- ask a (separate) follow-up question, linking to this one for context. It's up to you ;-)

            – SDF
            Jul 31 '18 at 20:15











          • edited since I don't think a new question makes sense. i would have left the accepted flag as well but then nobody but you would look at the question.

            – stefanct
            Aug 1 '18 at 14:30












          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
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f409859%2flistings-how-to-colorize-strings-between-angle-brackets%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          4














          Note: I'm making the assumption that the only angle-bracket strings you want colored are those that appear in lines containing a #. If there are other cases, I think my answer can be adapted.





          (The code is below. You can skip the explanations if you like.)



          You can't tell listings which of the strings starting with < should be colored and which shouldn't. But you can circumvent that using basic conditionals.



          You started in the right direction. Let's use a delimiter on <>:



          moredelim=[s][coloroncondition]<>


          with coloroncondition a custom macro giving a new color depending on a custom condition ifcoloranglebrackets:



          newcommandcoloroncondition{ifcoloranglebracketscolor{darkorange}fi}


          If we assume we want to color brackets in lines containing a #, then we can set the condition to true in these particular lines thanks to a delimiter on #:



          moredelim=**[l][coloranglebracketstrue]#


          The ** makes listings cumulate the "style" of that delimiter and any delimiter inside, thus the style for angle-bracket strings whithin lines containing a # will be {coloranglebracketstruecoloroncondition} (which will be ultimately sort of expanded to color{darkorange}), while the style for any other angle-bracket string will be {coloroncondition} (which will be expanded to nothing).





          Working example



          documentclass{article}
          usepackage[utf8]{inputenc}
          usepackage[T1]{fontenc}

          usepackage{xcolor}
          definecolor{darkorange}{HTML}{C87B0F}

          usepackage{listings}
          lstset{language=C,captionpos=b}
          lstloadlanguages{C}

          newififcoloranglebrackets
          coloranglebracketsfalse
          newcommandcoloroncondition{ifcoloranglebracketscolor{darkorange}fi}

          lstset{%
          stringstyle=color{darkorange},
          moredelim=**[directive][coloranglebracketstrue]#,
          moredelim=**[s][coloroncondition]<>
          }

          begin{document}

          begin{lstlisting}[gobble=4]
          #include <brackets.h>
          #include "quotes.h"
          std::cout<<text
          if a < b ...
          end{lstlisting}

          end{document}


          Output:



          colored C code





          About the directive option



          I replaced l by directive when matching the # delimiter. That option is not clearly documented, but I found it in listings source code. Apparently, LaTeX uses it to emphasize keywords starting with a # in C (#include, etc.). l can be used instead, but that would erase the default behavior on such keywords (which is, in this case, to put them in bold font).






          share|improve this answer


























          • Absolutely awesome, thank you! I'll forward a link to the current maintainer... maybe he wanna do something about the formatting itself or the documentation of directive

            – stefanct
            Jan 22 '18 at 13:21











          • However, the solution quickly breaks in most real-world cases where an identifier style is used, e.g., identifierstyle={color{blue}} (at least with the texlive version I am using right now. The first < stops highlighting of identifiers. :(

            – stefanct
            Jul 31 '18 at 18:25











          • @stefanct You're right, I didn't take identifierstyle into consideration. I can't find a fix right now. I suggest you to either 1- un-accept my answer and edit your question with a MWE that includes identifierstyle, or 2- ask a (separate) follow-up question, linking to this one for context. It's up to you ;-)

            – SDF
            Jul 31 '18 at 20:15











          • edited since I don't think a new question makes sense. i would have left the accepted flag as well but then nobody but you would look at the question.

            – stefanct
            Aug 1 '18 at 14:30
















          4














          Note: I'm making the assumption that the only angle-bracket strings you want colored are those that appear in lines containing a #. If there are other cases, I think my answer can be adapted.





          (The code is below. You can skip the explanations if you like.)



          You can't tell listings which of the strings starting with < should be colored and which shouldn't. But you can circumvent that using basic conditionals.



          You started in the right direction. Let's use a delimiter on <>:



          moredelim=[s][coloroncondition]<>


          with coloroncondition a custom macro giving a new color depending on a custom condition ifcoloranglebrackets:



          newcommandcoloroncondition{ifcoloranglebracketscolor{darkorange}fi}


          If we assume we want to color brackets in lines containing a #, then we can set the condition to true in these particular lines thanks to a delimiter on #:



          moredelim=**[l][coloranglebracketstrue]#


          The ** makes listings cumulate the "style" of that delimiter and any delimiter inside, thus the style for angle-bracket strings whithin lines containing a # will be {coloranglebracketstruecoloroncondition} (which will be ultimately sort of expanded to color{darkorange}), while the style for any other angle-bracket string will be {coloroncondition} (which will be expanded to nothing).





          Working example



          documentclass{article}
          usepackage[utf8]{inputenc}
          usepackage[T1]{fontenc}

          usepackage{xcolor}
          definecolor{darkorange}{HTML}{C87B0F}

          usepackage{listings}
          lstset{language=C,captionpos=b}
          lstloadlanguages{C}

          newififcoloranglebrackets
          coloranglebracketsfalse
          newcommandcoloroncondition{ifcoloranglebracketscolor{darkorange}fi}

          lstset{%
          stringstyle=color{darkorange},
          moredelim=**[directive][coloranglebracketstrue]#,
          moredelim=**[s][coloroncondition]<>
          }

          begin{document}

          begin{lstlisting}[gobble=4]
          #include <brackets.h>
          #include "quotes.h"
          std::cout<<text
          if a < b ...
          end{lstlisting}

          end{document}


          Output:



          colored C code





          About the directive option



          I replaced l by directive when matching the # delimiter. That option is not clearly documented, but I found it in listings source code. Apparently, LaTeX uses it to emphasize keywords starting with a # in C (#include, etc.). l can be used instead, but that would erase the default behavior on such keywords (which is, in this case, to put them in bold font).






          share|improve this answer


























          • Absolutely awesome, thank you! I'll forward a link to the current maintainer... maybe he wanna do something about the formatting itself or the documentation of directive

            – stefanct
            Jan 22 '18 at 13:21











          • However, the solution quickly breaks in most real-world cases where an identifier style is used, e.g., identifierstyle={color{blue}} (at least with the texlive version I am using right now. The first < stops highlighting of identifiers. :(

            – stefanct
            Jul 31 '18 at 18:25











          • @stefanct You're right, I didn't take identifierstyle into consideration. I can't find a fix right now. I suggest you to either 1- un-accept my answer and edit your question with a MWE that includes identifierstyle, or 2- ask a (separate) follow-up question, linking to this one for context. It's up to you ;-)

            – SDF
            Jul 31 '18 at 20:15











          • edited since I don't think a new question makes sense. i would have left the accepted flag as well but then nobody but you would look at the question.

            – stefanct
            Aug 1 '18 at 14:30














          4












          4








          4







          Note: I'm making the assumption that the only angle-bracket strings you want colored are those that appear in lines containing a #. If there are other cases, I think my answer can be adapted.





          (The code is below. You can skip the explanations if you like.)



          You can't tell listings which of the strings starting with < should be colored and which shouldn't. But you can circumvent that using basic conditionals.



          You started in the right direction. Let's use a delimiter on <>:



          moredelim=[s][coloroncondition]<>


          with coloroncondition a custom macro giving a new color depending on a custom condition ifcoloranglebrackets:



          newcommandcoloroncondition{ifcoloranglebracketscolor{darkorange}fi}


          If we assume we want to color brackets in lines containing a #, then we can set the condition to true in these particular lines thanks to a delimiter on #:



          moredelim=**[l][coloranglebracketstrue]#


          The ** makes listings cumulate the "style" of that delimiter and any delimiter inside, thus the style for angle-bracket strings whithin lines containing a # will be {coloranglebracketstruecoloroncondition} (which will be ultimately sort of expanded to color{darkorange}), while the style for any other angle-bracket string will be {coloroncondition} (which will be expanded to nothing).





          Working example



          documentclass{article}
          usepackage[utf8]{inputenc}
          usepackage[T1]{fontenc}

          usepackage{xcolor}
          definecolor{darkorange}{HTML}{C87B0F}

          usepackage{listings}
          lstset{language=C,captionpos=b}
          lstloadlanguages{C}

          newififcoloranglebrackets
          coloranglebracketsfalse
          newcommandcoloroncondition{ifcoloranglebracketscolor{darkorange}fi}

          lstset{%
          stringstyle=color{darkorange},
          moredelim=**[directive][coloranglebracketstrue]#,
          moredelim=**[s][coloroncondition]<>
          }

          begin{document}

          begin{lstlisting}[gobble=4]
          #include <brackets.h>
          #include "quotes.h"
          std::cout<<text
          if a < b ...
          end{lstlisting}

          end{document}


          Output:



          colored C code





          About the directive option



          I replaced l by directive when matching the # delimiter. That option is not clearly documented, but I found it in listings source code. Apparently, LaTeX uses it to emphasize keywords starting with a # in C (#include, etc.). l can be used instead, but that would erase the default behavior on such keywords (which is, in this case, to put them in bold font).






          share|improve this answer















          Note: I'm making the assumption that the only angle-bracket strings you want colored are those that appear in lines containing a #. If there are other cases, I think my answer can be adapted.





          (The code is below. You can skip the explanations if you like.)



          You can't tell listings which of the strings starting with < should be colored and which shouldn't. But you can circumvent that using basic conditionals.



          You started in the right direction. Let's use a delimiter on <>:



          moredelim=[s][coloroncondition]<>


          with coloroncondition a custom macro giving a new color depending on a custom condition ifcoloranglebrackets:



          newcommandcoloroncondition{ifcoloranglebracketscolor{darkorange}fi}


          If we assume we want to color brackets in lines containing a #, then we can set the condition to true in these particular lines thanks to a delimiter on #:



          moredelim=**[l][coloranglebracketstrue]#


          The ** makes listings cumulate the "style" of that delimiter and any delimiter inside, thus the style for angle-bracket strings whithin lines containing a # will be {coloranglebracketstruecoloroncondition} (which will be ultimately sort of expanded to color{darkorange}), while the style for any other angle-bracket string will be {coloroncondition} (which will be expanded to nothing).





          Working example



          documentclass{article}
          usepackage[utf8]{inputenc}
          usepackage[T1]{fontenc}

          usepackage{xcolor}
          definecolor{darkorange}{HTML}{C87B0F}

          usepackage{listings}
          lstset{language=C,captionpos=b}
          lstloadlanguages{C}

          newififcoloranglebrackets
          coloranglebracketsfalse
          newcommandcoloroncondition{ifcoloranglebracketscolor{darkorange}fi}

          lstset{%
          stringstyle=color{darkorange},
          moredelim=**[directive][coloranglebracketstrue]#,
          moredelim=**[s][coloroncondition]<>
          }

          begin{document}

          begin{lstlisting}[gobble=4]
          #include <brackets.h>
          #include "quotes.h"
          std::cout<<text
          if a < b ...
          end{lstlisting}

          end{document}


          Output:



          colored C code





          About the directive option



          I replaced l by directive when matching the # delimiter. That option is not clearly documented, but I found it in listings source code. Apparently, LaTeX uses it to emphasize keywords starting with a # in C (#include, etc.). l can be used instead, but that would erase the default behavior on such keywords (which is, in this case, to put them in bold font).







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Jan 11 '18 at 22:37

























          answered Jan 11 '18 at 22:28









          SDFSDF

          7951311




          7951311













          • Absolutely awesome, thank you! I'll forward a link to the current maintainer... maybe he wanna do something about the formatting itself or the documentation of directive

            – stefanct
            Jan 22 '18 at 13:21











          • However, the solution quickly breaks in most real-world cases where an identifier style is used, e.g., identifierstyle={color{blue}} (at least with the texlive version I am using right now. The first < stops highlighting of identifiers. :(

            – stefanct
            Jul 31 '18 at 18:25











          • @stefanct You're right, I didn't take identifierstyle into consideration. I can't find a fix right now. I suggest you to either 1- un-accept my answer and edit your question with a MWE that includes identifierstyle, or 2- ask a (separate) follow-up question, linking to this one for context. It's up to you ;-)

            – SDF
            Jul 31 '18 at 20:15











          • edited since I don't think a new question makes sense. i would have left the accepted flag as well but then nobody but you would look at the question.

            – stefanct
            Aug 1 '18 at 14:30



















          • Absolutely awesome, thank you! I'll forward a link to the current maintainer... maybe he wanna do something about the formatting itself or the documentation of directive

            – stefanct
            Jan 22 '18 at 13:21











          • However, the solution quickly breaks in most real-world cases where an identifier style is used, e.g., identifierstyle={color{blue}} (at least with the texlive version I am using right now. The first < stops highlighting of identifiers. :(

            – stefanct
            Jul 31 '18 at 18:25











          • @stefanct You're right, I didn't take identifierstyle into consideration. I can't find a fix right now. I suggest you to either 1- un-accept my answer and edit your question with a MWE that includes identifierstyle, or 2- ask a (separate) follow-up question, linking to this one for context. It's up to you ;-)

            – SDF
            Jul 31 '18 at 20:15











          • edited since I don't think a new question makes sense. i would have left the accepted flag as well but then nobody but you would look at the question.

            – stefanct
            Aug 1 '18 at 14:30

















          Absolutely awesome, thank you! I'll forward a link to the current maintainer... maybe he wanna do something about the formatting itself or the documentation of directive

          – stefanct
          Jan 22 '18 at 13:21





          Absolutely awesome, thank you! I'll forward a link to the current maintainer... maybe he wanna do something about the formatting itself or the documentation of directive

          – stefanct
          Jan 22 '18 at 13:21













          However, the solution quickly breaks in most real-world cases where an identifier style is used, e.g., identifierstyle={color{blue}} (at least with the texlive version I am using right now. The first < stops highlighting of identifiers. :(

          – stefanct
          Jul 31 '18 at 18:25





          However, the solution quickly breaks in most real-world cases where an identifier style is used, e.g., identifierstyle={color{blue}} (at least with the texlive version I am using right now. The first < stops highlighting of identifiers. :(

          – stefanct
          Jul 31 '18 at 18:25













          @stefanct You're right, I didn't take identifierstyle into consideration. I can't find a fix right now. I suggest you to either 1- un-accept my answer and edit your question with a MWE that includes identifierstyle, or 2- ask a (separate) follow-up question, linking to this one for context. It's up to you ;-)

          – SDF
          Jul 31 '18 at 20:15





          @stefanct You're right, I didn't take identifierstyle into consideration. I can't find a fix right now. I suggest you to either 1- un-accept my answer and edit your question with a MWE that includes identifierstyle, or 2- ask a (separate) follow-up question, linking to this one for context. It's up to you ;-)

          – SDF
          Jul 31 '18 at 20:15













          edited since I don't think a new question makes sense. i would have left the accepted flag as well but then nobody but you would look at the question.

          – stefanct
          Aug 1 '18 at 14:30





          edited since I don't think a new question makes sense. i would have left the accepted flag as well but then nobody but you would look at the question.

          – stefanct
          Aug 1 '18 at 14:30


















          draft saved

          draft discarded




















































          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.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f409859%2flistings-how-to-colorize-strings-between-angle-brackets%23new-answer', 'question_page');
          }
          );

          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







          Popular posts from this blog

          Biblatex bibliography style without URLs when DOI exists (in Overleaf with Zotero bibliography)

          ComboBox Display Member on multiple fields

          Is it possible to collect Nectar points via Trainline?