Regardless how the discussion on modular chemmacros is going to end chemmacros eventually will be upgraded to v5.0. And there are going to be some changes:
  • The package will have no package options any more. All setup will done through the \chemsetup command. I am aware that this will hit some users. On the other hand package options don’t make much sense for chemmacros: even now the package has a lot more options which already can only be set via \chemsetup so chance are people are using it already. Plus: package options can be a problem – ever had an option clash?
  • Some options will be dropped.
    • For instance the xspace option will no longer be provided and no macro will get an \xspace any more. This will probably the most annoying change for some users. If can give me good reasons for keeping this option let me know. In my eyes it only leads to inconsistent macro behaviour. Without it you know how macros act: the eat following spaces. With \xspace you can’t be sure any more…
    • The german option will no longer be provided. The language option suffices. At the moment the option is nothing more than an alias for language=german. I’d either should provide aliases for all the other languages. it’s easier just to drop german.
    • The ghsystem will be dropped. The option does nothing else than \usepackage{ghsystem} so there is no real advantage in having it.
    • The option Nu will be dropped. The option only affected the macro \Nu because some clash with mathspec. Now the macro will be called \Nuc.
    • The option synchronize will be dropped. It doesn’t make sense, really. Every place in chemmacros where atoms are typeset chemformula’s macros are used, anyway. So chemmacros and chemformula are synchronized. Everything else doesn’t make sense.
    • The option greek will be dropped changed in favor of another even more comfortable mechanism (thanks to changes in chemgreek inspired by requests by Martin Hensel.
  • A few commands will change their syntax. This mainly concerns macros for defining stuff so no document content should break because of this once the preamble is updated accordingly. \NewChemReaction will change its syntax or rather its options.
  • This will probably annoy people, I’m afraid: a number of options will change, mostly because they’ll belong to new module names. I’ll try to keep this to an minimum but in order to be able to make chemmacros extensible with modules/libraries I need to do some re-ordering.
  • I’m not sure about this: I’d like to drop the \listofreactions functionality. Has this ever been used by anyone? Is it really useful? Please comment below what you think about this.
  • chemmacros will provide a scheme float, hopefully flexible enough for the different classes and packages that handle floats.
  • A new \isotope macro that will automatically fetch the atomic number and the most common nucleon number for a given element symbol and typeset the isotope. So \isotope{C} should give \ch{^{12}6C}, \isotope{14,C} should give \ch{^{14}6C}, a starred variant \isotope* should omit the atomic number. This is not implemented, yet, so let’s hope for the best. 🙂
  • There’ll be a macro \NewChemIUPACShorthand which makes it possible to add other shorthands like | or ^ for usage in \iupac. There’ll also be the corresponding \Renew and \Declare versions for changing the existing definitions. Finally there’ll also be a \RemoveChemIUPACShorthand for deleting existing shorthands.
Now it’s your turn: what would you like to be improved or changed in chemmacros? What would you like to see as additional features? PS: as a side effect of chemmacros’ development internal changes in chemformula and bohr will happen and a new package elements will be published. There is something to wait for this summer! 🙂

6 thoughts on “chemmacros development

  1. Clemens says:

    Currently I’m thinking that I will make chemmacros modular… people either haven’t seen this post and the modular chemmacros one or they just don’t care…

  2. Mike says:

    Hi, I’ve read this post through getting problems with my document. At the end of next week I will get closer to my problems. But I hope it will depend on these changes.
    Relating to your question: I would prefer the \listofreactions function. I use it.

    1. Clemens says:

      Thanks for your comment! I already decided to keep it. Your remark reassures me that this was the right decision.

  3. Mike says:

    Thats really nice.
    Are the changes above already made? I use the newest version (4.7). I mean, is v4.7 affected?

    1. Clemens says:

      The code is already written but not published, yet. Also, in order to minimize problems for people in the middle of a document when updating (a bad idea but these things happen) the package will provide a compatibility option:


      This way the new features won’t be available but the document will still compile as before… New documents then can switch to the new version.

  4. Mike says:

    Thanks for the tip. Now it works as before.

Leave a Reply

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