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 anoption 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. Thelanguage
option 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
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 withmathspec
. 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 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.\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,
\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
\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.
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…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.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.