Combine whalogen with this repository?

[schang412]

Hi,

@Ants-Aare brought to my attention this repository and GitHub organization. I am the author of https://github.com/schang412/typst-whalogen. It seems like this package is trying to provide similar features as whalogen.

Is there interest in combining these two packages together? If so, I can archive my typst-whalogen package and make contributions here.

[Ants-Aare]

hey @schang412 , thanks so much for reaching out! I started out working with whalogen and actually wrote a couple of longer projects with it for my university assignments and have been incredibly happy with how capable and reliable it is! Typsium right now doesn't have feature parity with whalogen yet. If you were to replace the ce method with the typsium ce method the project would be jumbled and have a bunch of errors.

@tryptophawa was the one who wrote the formula displaying methods, he doesn't have that much time the coming weeks because he has exams. He chose to go for a regex based approach for parsing the formulas, which has the benefit that regex is running on the lower level and is quite optimised. Making a state machine inside of typst has a bit more overhead. I know he did some performance test and that typsium was faster. Honestly though... I feel like we shouldn't make performance a main deciding factor this early on, I haven't had issues with whalogen in my bigger projects with hundreds of formulas displayed. I actually think that having a statemachine like in whalogen has some unique benefits I think could be important:

The vision I have for not just this formula rendering package, but the project as a whole, is that it should be way more programatic i.e. you define variables and use them all over the place instead of manually writing so much text. I saw that there was a PR in whalogen to add support for variables using some weird new syntax, and even my own PR which introduces oxidation numbers introduces weird new syntax, and I feel this is not the right solution. We should limit the amount of new non-typst syntax to make it easier for users. The main reason for these weird solutions is that whalogen just works with strings. and we need to have some sort of metadata about specific characters to correctly typeset them. So my thinking is that we should use the content body instead of strings: ce[H2O] vs ce("H2O") this way we can use the variables with regular typst syntax: ce[5#methane -> 5#co2] I already have this working and it converts variables to regular rendered formulas, but working with content is a little bit more complicated, and sadly regex doesn't work that well with content. The other thing is that I oftentimes found myself needing to explain specific parts of my reaction and using underbrace or overbrace was great for this. there actually is an example in the whalogen manual for this, but even there the example is a bit misleading. when trying to regularly use overbrace in formulas it quickly becomes harder to type, because you have to separate your single ce into 5 different ce calls: ce("a+b-> c") vs overbrace(ce("a"), A) + overbrace(ce("b"), B) ce("&->") overbrace(ce("c"), C)

I think, even though it would be a bit more complicated to pull off it's definitely possible to do it this way:
ce[overbrace(#ethanol, E) + overbrace(H2O, H) -> ]
Also on another note: We have the core developer of the alchemist package onboard, and he's starting to work on a smiles parser. So my thinking is that we should keep in mind that we will have in the future an almost exactly similar API for smiles and regular formulas, maybe just adding '-smiles' to the method like this:
ce-smiles[overbrace(#ethanol, E) + overbrace(H2O, H) -> ]
And it would overbrace the rendered out smiles structure if the ethanol variable has a field with a smiles code, while keeping the rest the same looking.

now for something like this using our current regex approach would be pretty much useless and we would definitely need a statemachine like whalogen.

Anyways, I have lots more things I'd like to talk about, but it's getting long, so here's a summary:

• better awareness of meaning of formulas (weight, composition of elements, etc)
• we need a "Reaction" figure which can be referenced similar to equations, math, theorems, etc. ideally already part of the core featureset
• I'm currently working on defining molecule variables, elements are already mostly done and typsium has a database of all elements (including Electronegativity, radiuses, weights, and so on)

Please let me know what you think!

[Ants-Aare]

to answer your original question:

• We would absolutely love to have you onboard, I loved what you did with whalogen!
• I don't think it makes sense to simply copy paste all whalogen code into the typsium package, as we are working on I think a very different approach with different goals, but the core structure of whalogen would be suitable.
• I think it makes more sense to work on typsium and wouldn't put too many resources into whalogen. I think it makes sense to transfer whalogen to the typsium organisation, just for hosting it. and if someone wants to fix something they can make a PR and more people can review it, it gets merged faster and everything is not so reliant on you as a core maintainer.

[Ants-Aare]

I sent you an invite as an owner of this organization

[tryptophawa]

@schang412 I was very grateful for you to visit my project, and typsium and whalogen take two different pathways.

I built Typsium because chem-par wasn't compatible with it a few months ago when I tried to use my old template with Typst 0.12, and I want to try a full regex rule parser. So, I built this package.

---

I personally don't think Typsium should be a competitor for Whalogen since Whalogen has done so many things ahead. Maybe we can cooperate to develop both packages together. For instance, I could help Whalogen maintain features or subtract subroutines from your code, and you may help me grow more functions and change the input format more reasonably.

[tryptophawa]

@schang412 I was very grateful for you to visit my project, and typsium and whalogen take two different pathways.

I built Typsium because chem-par wasn't compatible with it a few months ago when I tried to use my old template with Typst 0.12, and I want to try a full regex rule parser. So, I built this package.

I personally don't think Typsium should be a competitor for Whalogen since Whalogen has done so many things ahead. Maybe we can cooperate to develop both packages together. For instance, I could help Whalogen maintain features or subtract subroutines from your code, and you may help me grow more functions and change the input format more reasonably.

For example, help us to fix #3

[Ants-Aare]

btw Robotechnic started working on the smiles parser just a couple days ago, it's going to be a web assembly plugin and written in C! pretty cool!!! Can't wait to have this capability in combination with the molecules database...

btw check it out, we already have 4 typsium packages on the typst universe