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?
On other new concerning the active development of chemmacros please see the post chemmacros development. I am very interested in you opinion oder there, too!

## 12 thoughts on “modular chemmacros”

1. Johannes_B says:

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.

\documentclass{article}
\usepackage{chemformula}
\begin{document}
\end{document
}

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.

1. cgnieder says:

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.

1. Johannes_B says:

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.

1. cgnieder says:

I guess for a real document the mere loading of packages has a marginally effect on loading time.

Probably true. The chemmacros manual is very much slowed down be the use of the reaction and reactions environments (both of which I am not very happy with to be honest but I can’t happily drop them any more…).

2. cgnieder says:

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! 🙂

3. canageek says:

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.

1. cgnieder says:

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…

2. cgnieder says:

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’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 chemnum package 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 chemmacros is concerned this is not really an issue: all features currently described in the chemmacros manual would still be in the chemmacros manual. I am certainly not planning to write a manual for each library. More like: one section in the manul per library…

3. cgnieder says:

What if I made chemmacros modular but all libraries would be loaded per default? Then your concern 2) wouldn’t really be a problem would it. BTW: which features of chemmacros do 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 chemmacros on their own.

4. cgnieder says:

Another idea: I could freeze chemmacros in 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…

5. Mike says:

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.

1. Clemens says:

Thank you very much for your input! Very much appreciated! 🙂

In my experience using the reaction environment is not one of the most common tasks. Most people seem to use equation environments and use chemformula‘s \ch inside to have math and chemistry equations numbered the same. I have decided to preload these modules:

• base (programming concepts irrelevant for the user),
• lang (language support),
• greek (upright greek support),
• chemformula (chemformula integration),
• acid-base (writing \pH and stuff),
• symbols (provide common symbols like \standardstate,
• charges (support various kinds of charges and charge symbols),
• particles (support for particle macros like \prt and \el),
• phases (support for phase descriptors), and
• nomenclature (the \iupac macro 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),
• isotopes (new functionality),
• mechanisms (the \mech macro),
• newman (the \newman macro),
• orbital (displaying orbital shapes),
• reactions (reaction environments),
• redox (oxidation numbers and redox reactions),
• scheme (a scheme floating environment),
• spectroscopy (the \NMR macro and the experimental environment and related stuff),
• thermodynamics (the \enthalpy macro and sibblings),
• units (siunitx integration 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 chemmacros but add a compatibility option. (I’ve done this in a way that I even can fix urgent problems in v4.7…)