OK, it’s been a while since I’ve posted anything. But now it’s time to discuss a few ideas I have about chemmacros. As you are probably aware if you are a user of the package: it provides lots of different stuff. At least in my experience it is rarely the case that you need all of its features. So the idea is to make chemmacros a modular packages. By default let it activate only the basic features, the particle macros, say, and all other features are then loadable per use case. My idea is to have a similar mechanism like TikZ/pgf:
chemmacros then would be split in the libraries particles, iupac, units, acid, charges, redox, mechanisms, thermodynamics, spectroscopy, reactions, phases, newman and orbitals, say. My questions to you:
- What do you think in general of this idea?
- What do you think about the library list? Is this a sensible list or should features be bundled in a library, particles and phases, say?
- Which library or libraries should be loaded as default? What should be the basic functionality of chemmacros?
12 thoughts on “modular chemmacros”
Initially i thought, “wow, great idea, get rid of that arrow stuff and decrease compile time.” But arrows are one of the most important things in a chemical formula. On my (quite old and powerless) machine, the following MWE takes 2 seconds to compile, much of it due to pgf.
It would certainly have the advantage, that a user is aware that he does something, i.e. explicitely reuire a library to work with it.
If the library `units` would not be loaded, would the package still load `siunitx`?
Can you see any improvements possible improvements in performance (compile time)?
Would a splitting into libraries include the other packages of the bundle, basically making the functionality available as a chemlibrary (in addition to the package right now, or make the package just load the chemlibrary)?
If so, what happens to the documentation?
What should be the basic functionality? Not sure, i am not a chemist. But i think very basic `chemformula` functionality should be the default, everything else by request.
Thanks for developing the package even further.
Although chemformula originally started as part of chemmacros I nowadays consider it a standalone package which is used by chemmacros like it uses siunitx.
I believe that if a library (let’s call them that for now) needs a package then the library should load it. So if a library is not used the corresponding package may not be loaded any more. So: no units library no siunitx.
chemformula, chemgreek and ghsystem will stay independent packages maintained and updated on their own. The development is completely independent from chemmacros nowadays.
As for compilation time: you example needs 1.027s on my laptop. If I exchange chemformula with chemmacros it increases to 1.977s. So: other things besides pgf slow compilation time down. This means splitting chemmacros into libraries may indeed have impact on compilation time. It may also help me find out where this happens and if I can do anything about it.
I guess for a real document the mere loading of packages has a marginally effect on loading time. But still i think the splitting in libraries might be a good idea.
Right now, many users load packages without caring what it does, because of templates.If a template loads
chemmacros, but not any libraries, This could reduce implicit package incompatibilities. Altough, if a future template loads all libraries, the effect is gone.
I’d really like to hear more input from people with more expertise.
Probably true. The chemmacros manual is very much slowed down be the use of the
reactionsenvironments (both of which I am not very happy with to be honest but I can’t happily drop them any more…).
The more I think about it the more I like the idea. Still: before I go ahead it would be nice to hear thoughts of other users, too! 🙂
1) What is the advantage? Compile time seems to be to be pretty negligible.
2) This is going to lead to more people having trouble with it. They accidentally don’t load something, things don’t work, then they have to get help.
I already have trouble searching through the various manuals when I need to figure out which manual what I need is in.
To be honest: compile time is one of the reasons for me. The chemmacros manual takes several minutes to compile – noticable longer than other documents of a similar length. (I’ll give data in a while…) Personally I try to avoid using chemmacros as much as I can because of this.
The other reason is maintainability. But this is a minor reason, really…
I’m not so sure about this… sure, there probably would be some confusion at first as always when there are changes in software but I don’t think that it would be a major problem. When the
chemnumpackage completely changed it’s macro names and quite a bit of the syntax in the step from v0 to v1 I got no complaints and only very little questions on how to solve something with the new version.
Not knowing which manual to look in is not knowing which package is providing a certain feature one uses but as far as this change of
chemmacrosis concerned this is not really an issue: all features currently described in the
chemmacrosmanual would still be in the
chemmacrosmanual. I am certainly not planning to write a manual for each library. More like: one section in the manul per library…
What if I made
chemmacrosmodular but all libraries would be loaded per default? Then your concern 2) wouldn’t really be a problem would it. BTW: which features of
chemmacrosdo you use regularly? Which do you rarely use?
About 1) I have another possible advantage: in principle this would allow users to write libraries themselves and to extend
chemmacroson their own.
Another idea: I could freeze
chemmacrosin its current state and publish the modular version under a different name,
chemistry, say… that way we can have both worlds but to be honest I am not much convinced of this idea, yet…
The idea is great (given that there is a good documentary :-).
Basic functionality should be: writing reactions (with reaction environment and counting itself), using names and formulas in normal text. Perhaps drawing formulas (lewis etc.).
Most of the other functions are totally great but it should be activated if needed. I would prefer to have a long list for setup instead of things I do not need for my current document.
Relating for future plans:
I would put the all new modularised chemmacros in a new package with a new name: chemmacrosmod (for modularised) or chemmod or chemistrymod or something like that. The old (not modularised) chemmacros gets bugfixes if needed (if you’ve been informed). Otherwise there will be no changes.
This is status for, lets say, for 1 or 2 years. This needs to be communicated, clearly. After this period, all users have enough time to make the change to the future and you can bring chemmacros to an end.
The old package should be removed everywhere, if possible. CATN, GitHub etc. Otherwise there will be huge chaos or knot garden. If it is removed, no (new) one can use it and is forced to use the new modularised package.
These words are just my opinion.
Thank you very much for your input! Very much appreciated! 🙂
In my experience using the
reactionenvironment is not one of the most common tasks. Most people seem to use
equationenvironments and use
\chinside to have math and chemistry equations numbered the same. I have decided to preload these modules:
base(programming concepts irrelevant for the user),
greek(upright greek support),
symbols(provide common symbols like
charges(support various kinds of charges and charge symbols),
particles(support for particle macros like
phases(support for phase descriptors), and
\iupacmacro and all the related stuff).
Additional modules are going to be
tikz(mainly programming support for tikz in expl3, irrelevant for the user),
all(a pseudo module which simply loads all modules),
orbital(displaying orbital shapes),
redox(oxidation numbers and redox reactions),
\NMRmacro and the
experimentalenvironment and related stuff),
\enthalpymacro and sibblings),
siunitxintegration and a few “chemical” units), and
xfrac(support for fractions, used by other modules and not very interesting for the user).
I’ve also decided to still call it
chemmacrosbut add a
compatibilityoption. (I’ve done this in a way that I even can fix urgent problems in v4.7…)