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
\chemsetupcommand. 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\chemsetupso chance are people are using it already. Plus: package options can be a problem – ever had anoption clash? - Some options will be dropped.
- For instance the
xspaceoption will no longer be provided and no macro will get an\xspaceany 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\xspaceyou can’t be sure any more… - The
germanoption will no longer be provided. Thelanguageoption suffices. At the moment the option is nothing more than an alias forlanguage=german. I’d either should provide aliases for all the other languages. it’s easier just to dropgerman. - The
ghsystemwill be dropped. The option does nothing else than\usepackage{ghsystem}so there is no real advantage in having it. - The option
Nuwill be dropped. The option only affected the macro\Nubecause some clash withmathspec. Now the macro will be called\Nuc. - The option
synchronizewill 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
greekwill bedroppedchanged in favor of another even more comfortable mechanism (thanks to changes in chemgreek inspired by requests by Martin Hensel.
- For instance the
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.\NewChemReactionwill 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
\listofreactionsfunctionality. Has this ever been used by anyone? Is it really useful? Please comment below what you think about this. - chemmacros will provide a
schemefloat, hopefully flexible enough for the different classes and packages that handle floats. - A new
\isotopemacro 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
, \isotope{14,C}should give
, 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
\NewChemIUPACShorthandwhich 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\RemoveChemIUPACShorthandfor deleting existing shorthands.
Currently I’m thinking that I will make
chemmacrosmodular… people either haven’t seen this post and the modular chemmacros one or they just don’t care…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
\listofreactionsfunction. I use it.Thanks for your comment! I already decided to keep it. Your remark reassures me that this was the right decision.
Thats really nice.
Are the changes above already made? I use the newest version (4.7). I mean, is v4.7 affected?
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.
Thanks for the tip. Now it works as before.