Somewhat related to #5 but not quite the same. The solution to #3, introduced by the pull request #14, breaks the capability of performing line breaks inside cpfunc macros. You can include newline and linebreak macros inside cpfuncs, but the latter macros seem to be ignored, best as I can tell. Using \\ causes compilation errors.

I'm not sure what the solution is, but it would be good to re-enable the capability since sometimes there isn't really anything for it but to break a cpfunc across multiple lines.

LaTeX3 is (eventually) supposed to be the way of the future for LaTeX, especially with regards to package development. From what I understand, it should provide a much cleaner and more logical syntax, with a great many tasks being more straightforward to accomplish (though not necessarily less verbose - that's not inherently a bad thing).

On that basis, it would be a good thing to change over to using the LaTeX3 approach, for the sake of anyone who ends up trying to maintain or contribute to this package. Doing so might even show the way for how to resolve some of the other open issues.

Currently, though, making the switch from LaTeX2e to LaTeX3 isn't particularly easy. The resources on using LaTeX3 for package development all seem to assume that the reader is already familiar with LaTeX3. There doesn't appear to be any sort of "Introduction to LaTeX3 for LaTeX2e package developers" (at least, not one I could find). E.g. if you look at the list of publications for LaTeX3, while some of them are relatively recent, none of them really make it clear how to get started.

With the latest release, promoters and inhibitors also draw arrows ala rules when using \cppromoter and \cpinhibitor. That space should be empty instead for them.

Right now cpfunc macros make their brackets slightly larger than standard. This behaviour is hard-coded. It would be preferable if the size of the wrapping brackets could automatically re-scale themselves. So if there are no inner brackets, the cpfunc's brackets are normal size. Alternatively, if there is one set of inner nested brackets, cpfunc's brackets become one size larger. Two nested levels of brackets mean that cpfunc's brackets become one size larger again, and so on. It might be necessary also to go into using smaller brackets if the nesting becomes significant enough.

The cpruleset environment works quite well for typesetting cP systems rules (or, at least, it seems to so far), but there currently isn't any built-in functionality in this package to cross-reference the rules. E.g., using label inside a cprule and then ref elsewhere right now just ends up returning the number of the section containing the rule. This should be improved so that automatic cross-referencing can occur, just as with tables, figures, etc.

At a minimum, the final implementation should work with the standard ref command, hyperref's autoref command, and cleveref's cref command.

David Orellana Martín has released a new LaTeX package called membranecomputing. It seems to aim to support most types of P systems except for cP systems (there seems to be no mention of cP systems in the documentation). In some ways, it appears to be similar to this package, but in other ways quite dissimilar - probably partly at least because it is trying to support a much wider range of functionality and P systems variants.

It would be good to align this package more to membranecomputing, if just because it will be easier to get people looking more at cP systems that way. The ideal long-term goal would be to integrate this package into membranecomputing, but that will probably be a long way off yet. For one thing, I haven't actually found the source code for membranecomputing yet.

Since this package is (currently) just the one .sty file, including it alongside the .tex files isn't really a big deal. To aid discoverability and re-use by other people, it would be good to publish this package to CTAN eventually.

There are no plans to do so at the present point in time, however. It's for future work 😅

Currently, Objects Groups show a snapshot of the objects present in a given top-level cell at some point during the system's evolution, but there is nothing to display what state the system (or top-level cell, if they have separate states) is in. It would be good to add something into the cpobjects environment, or a new cpstate command to go inside a cpobjects environment, that is then typeset nicely to show the state of the system. How this should look is entirely unclear, however.

Thinking about it further, it might be a good idea to add in some more elements, explaining e.g.

• The current state of the system
• The previous state of the system
• The numbers of the rules applied to make the transition
• Perhaps even the actual specific rules applied themselves. Preferably, I could get rule cross-referencing working, and then that way only the labels for the rules need to be included in a given Objects Group's declaration, and the rest could be worked out automatically.
• The previous Objects Group that the current one has been derived from, at least when there has only been a single step between them

None of this is strictly necessary, but it would probably go a long way to helping casual readers orient themselves as they follow along with an example.

If someone wants to break a rule over multiple lines (usually because leaving the whole thing on one line would make it spill out past the edge of the box), then they have to specify the line break manually and the correct number of ampersands required by the encapsulating array environment, to get everything to line up again. This is fiddly, messy, error-prone and makes the cprule a 'leaky abstraction'. It would be much better to have a package-specific linebreak command included which can automatically adapt itself to whichever part of the rule it is in.

It is entirely unclear at this point how to implement such a thing, though.

Currently, the only versions of the \cpruleset and \cpobjects environments include a framing box automatically. It might be the case in the future that somebody would prefer to have a version that doesn't include the box at all.

Implementing this should be as simple as making the use of the \framed environment conditional on something. Precisely what interface to present to the user is a different question, though. The best ideas so far are:

1. A \cpruleset* version, e.g.

\begin{cpruleset*}
ruleset as normal
\end{cpruleset*}

2. Including an optional parameter with the declaration, such as \cpruleset[noframe] style, e.g.

\begin[noframe]{cpruleset}
ruleset as normal
\end{cpruleset}