search

typst-community / glossarium

Glossarium is a simple typst glossary.
MIT License
41 stars 11 forks source link

feat: add overrides `num-columns` and `group-heading-level` #60

Closed swaits closed 1 month ago

swaits commented 1 month ago

Before this change, group-heading-level defaulted to reusing the last heading level found in the document. This is unlikely to always work for users. This new parameter allows users to override the default.

Additionally, to give users some ability to style the output without needing to override user-print-glossary, the new num-columns parameter gives users the ability to control the number of columns groups are printed in.

quachpas commented 1 month ago

Thanks! Will take a look at the group-heading. For the columns feature, I'd rather we discuss it in a separate issue/PR. I don't like the idea of giving a columns container TBH.

swaits commented 1 month ago

Understood. Glad to move it to a new PR.

If columns is not set (ie default 1), we could make sure it's not in a column container. IOW, only contain it in #columns() when the user asks for something >1. Does this make it more amenable? The reason I added it, for my own need, is because index-style glossaries are often multi-column. It felt like something users may commonly want, and this way they can get it without the trouble of re-implementing a bunch of functionality in the library.

quachpas commented 1 month ago

I agree, multi-column glossaries are very common, but I cannot think of a good reason why glossarium should take on the responsibility of the document layout. Typst exposes a very intuitive interface, where the end user can just set columns for the glossary. By default, I think any layout behaviour is outside glossarium's scope. We do need better documentation for sure, more examples perhaps.

Le mar. 1 oct. 2024 à 20:01, Stephen Waits @.***> a écrit :

Understood. Glad to move it to a new PR.

If columns is not set (ie default 1), we could make sure it's not in a column container. IOW, only contain it in #columns() when the user asks for something >1. Does this make it more amenable? The reason I added it, for my own need, is because index-style glossaries are often multi-column. It felt like something users may commonly want, and this way they can get it without the trouble of re-implementing a bunch of functionality in the library.

— Reply to this email directly, view it on GitHub https://github.com/typst-community/glossarium/pull/60#issuecomment-2386628897, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE3OKGUXSY7RESCPPCCSPKDZZLPRHAVCNFSM6AAAAABPEMNYOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBWGYZDQOBZG4 . You are receiving this because you commented.Message ID: @.***>

swaits commented 1 month ago

I'm fine with that. I think my challenge with the current interface for overriding styling is that it forces the user to mix logic with styling. I don't want to re-implement for g in groups { for e in entries { ... } }. I just want to say, hey, here's how to style this part of the hierarchy. Until these concerns are split apart, we'll continue to see high friction to theming, and thus, few or no themes published or contributed back.

But again, I understand your point, completely. It is also weird to take what I'm saying in the complete opposite direction and start polluting the glossarium internals with styling overrides.

swaits commented 1 month ago

BTW, for some inspiration, check out https://en.wikipedia.org/wiki/Citation_Style_Language if you haven't seen it already. It's not perfect, but it does completely separate logic from presentation.

quachpas commented 1 month ago

I think my challenge with the current interface for overriding styling is that it forces the user to mix logic with styling.

Yes, the main point of the current styling is to allow advanced users who are familiar with Typst scripting to only modify the relevant elements.

For the columns option:

Finally, thanks for the discussion, it's great to know other people are interested in making glossarium better

tfachada commented 1 month ago

Hi, two questions about the group-heading-level fix:

1- Sorry for bothering, but what's the current status on this?

2- Wouldn't it be better if the default value for group heading levels, instead of being "the same as the previous", was "the same as the previous, plus one"? I understand that this PR aims to allow the user to choose, but the thing is that the default value before Typst 0.12 was "plus one", and honestly it seems more logical to me (I'm open to counter-arguments though). Besides, I've only just noticed, completely by chance, that the current value breaks my post-0.12 template, and I suspect that this breakage is the same with the majority of the users at this point.

swaits commented 1 month ago

I don't think any default makes sense. Some users might want it same as before. Others might want it before+1.

I've since found a workaround myself so I'm all set. But I'd say if you see more people run into this then we should consider adding some flexibility and control for heading level.

tfachada commented 1 month ago

My point with +1 being more logical is that a group is supposed to be a subcategory of terms within the glossary, and as such having a h1 "Glossary" title followed by also h1 titles for groups would be the same thing logically (in terms of outline) as multiple glossaries. Though then again, the workaround I found, which I suppose may be the same as yours, would be to print multiple glossaries too but with h2 titles before the subcategory ones, so the group feature might be pointless.

quachpas commented 1 month ago

1- Sorry for bothering, but what's the current status on this?

I'll probably split the commit and implement the group-heading-level + 1 by default, and add group-heading-level parameter.

quachpas commented 1 month ago

Closing in favor of #73. I'll create an issue to track the columns.