Lemmify vs ctheorems: How do they compare?

Basically the title.
Currently we have two packages for typesetting theorems?
Did you try both? Which one did you choose and why?
What are some advantages of one over the other?

1 Like

They are both very good packages. I have used ctheorems for a long time, but I switched to a custom implementation, because it did not suit my use case anymore.
At the end of the day, which package you choose is a matter of needs and preferences.
For example, using ctheorems, I do not think the internal counter is exposed, making it difficult to share it with other elements, across math.equations for example. See Share the internal counter with other environments · Issue #32 · sahasatvik/typst-theorems · GitHub.
The interfaces are wildly different between ctheorems and lemmify, but the latter seems to be updated more frequently in the last few months.

2 Likes

In fact there is another competitor: great-theorems

This package does cleanly separate between theorem functionality and counter functionality. In fact, the counter functionality is put into a whole nother package called rich-counters. This is one of the reasons why I wrote the package.

I hope you will give it a try! @Sinthoras @quachpas

1 Like

Hey, thank you for the suggestion. I will give it a try. :)

I see the point, that it is more clean to separate the counter and the theorem functionality, and it is absolutely no problem for me, but I think many end users, who don’t think too deeply about which solution is the best, would prefer to just have to call one package to get working theorems with custom numbering out of the box.
So I suggest you to maybe call rich-counters inside great-theorems automatically?

Edit: @jbirnick I actually asked a question about your package here.

I’d like to briefly chime in and mention the package I have recently published on the Universe called frame-it. It fits the same use case like lemmify and ctheorems but tries to me more flexible and visually verbose. I’m always looking for feedback. Here it is on GitHub and the Universe.

1 Like

Does your package support some type of custom numbering or is there a workaround using rich-counters or similar? For a mathematics writing use case I personally find it more readable, comprehensive and searchable to have something like “theorem 3.1.2” instead of “theorem 24”

1 Like

I tried to avoid this as I wanted to focus on the styling. However, I just tried to do i it using additional show rules using i-figured for example. Unfortunately, it didn’t work for some reason. Because I know that it is important to achieve this, I might get around to implementing this in a custom manner when I have time (1 month from now unfortunately).
Do you think you could open up an issue on my repo explaining briefly how the result should look and which kind of API you would prefer?

Definately. I’m not familiar with any api that might help, but I’ll look into it to make a proper request and open an issue.

Very nice, thanks! You don’t have to put too much thought into the API/syntax, it’s probably gonna evolve anyway. Also, instead of shipping my own way I want to try again to be able to pick up on already defined ways of number without getting in the way in weird ways.

With that in mind, do you happen to know some ways/packages to achieve that with ordinary figures? I would need them as a starting point to not have my logic for layouting get in the way.

As for providing my own syntax, what requirements do you personally have for the feature?

  1. Specifying a custom numbering (of course)
  2. Which level of nesting should the numbers be able to track?
    1. Are there packages like i-figured that it needs to integrate with?
  3. Do you only need the counter to reset on headings or are there different types of elements like pagebreaks or whatever which should do that

Also, I think it’s quick and easy to implement a show rule for the simplest casebso I might do it tomorrow it I find time.
:heart: