feat: add overrides num-columns and group-heading-level

[swaits]

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]

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]

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]

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 <#60 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE3OKGUXSY7RESCPPCCSPKDZZLPRHAVCNFSM6AAAAABPEMNYOWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBWGYZDQOBZG4> . You are receiving this because you commented.Message ID: ***@***.***>

[swaits]

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]

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]

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:

• How about this? I'd rather not have the multi-columns style as an option of the default theme. Could you put it in a separate theme by overriding default-print-glossary? Just define it again in a file called multi-columns.typ with any new additional options you'd think are elevant, e.g., columns.
• For the group heading level, as long as you remove the columns, I will test and review

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

[tfachada]

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]

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]

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]

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]

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