a new chemmacros – but how?

I have written earlier about a new concept for chemmacros and about the current development of chemmacros. I really want to go along with e idea of modularity. In fact so much that I already have a draft completed (without manual and probably a number of bugs but still…). The big question is, though: How do I procede without annoying all the users of chemmacros? If I am consequent with the modularity then there need to be breaking changes.

Currently I see three options of how to procede:

  • Make the changes, publish the new chemmacros and live with the fact that users will be annoyed.
  • Publish the new version as new package (name?) and deprecate chemmacros. This would mean people would eventually need to change packages if they want new features and bug fixes. chemmacros could issue a warning when loaded that it is deprecated and that there is a successor. Similar changes are not unprecedented: think of glossary and glossaries, or the various unit packages and siunitx.
  • Add loads and loads of compatibility code which gently directs users towards the new syntax/option names/… – this is the version I favor the least as it is a lot of work and there is no guarantee that I’ll cover all cases.

I’d appreciate it a lot if users of chemmacros could give me some feedback (e.g. below in the comments) what way they would favor! Or do you see another option on how to procede? Any thoughts are greatly appreciated!

Picture: © Thorben Wengert/pixelio


  1. Johannes_B

    I am in favour of deprecating chemmacros and provide a successor. Would be easier for the support forums as well, because there will be a great amount if the first option would be chosen.

      • Johannes_B

        Can’t say i am a person who likes to make decisions. Thinking from a standpoint that tries to ease the access to starters, i think chemsupport might be a good name.

    • I like chemcomp as package name: could read chemistry comprehensive (which has two meanings already) and chemistry companion.

      Nevertheless I am still struggling. Finding a suiting package name is harder than I thought! I definitely don’t like chemmacros2 or chemmacrosx (although this would be the easiest solution and probably easiest to understand for users, too)! The ltx-versions imply some intrinsic connection to the LaTeX format. So they’re not well suited! chemsupport is OKish, better than chemhelper or something but for reasons I can’t put my fingers upon I don’t quite like it, either.

  2. There is actually a fourth way: the biblatex way:

        % stuff ...
    • Johannes_B

      biblatex needs to do that in order to support the older BibTeX-method. Same user-interface with a different implementation, i would say .995 users don’t know about that and don’t care. I think that would be the case here as well. Using the new package as default, and getting the current functionality via option version=chemmacros? I like it somehow, but it will be strange once chemsupport (or whatever it will be called) is far superior.

      • The point is that you have one package on the surface (biblatex) but two packages underneath. That way I may be able to stay with chemmacros and use the old and the new version underneath… I need to think about this

  3. I finally decided to go a similar way that biblatex does: the package will still be called chemmacros and can be called


    to get the old version loaded. Using no compatibility option or compatibility=5.0 (or higher for future versions) will load the new package with its modularity features.

    % \usepackage[compatibility=4.7,language=english]{chemmacros}




      A + B -> C  \\
      D + E -> F "\label{bla}"


Leave a Reply

Your email address will not be published. Required fields are marked *