More flexible splitting of the bibliography - #18
Conversation
to match the Hayagriva field names
|
Hi @alyst, thank you for your contribution. Unfortunately it is really hard to review this PR as it makes many unrelated changes as well. From what I could quickly see, it
Also there's stuff about citegroups in there that has nothing to do with the features listed in your PR description. Some changes are imo outright detrimental:
The regression of I appreciate you helping out with Alexandria, but it would really be important to bring this PR in a better shape. I would maybe leave this PR as-is, and create new, more focused PRs for individual features you'd like to see. Even if the feature is somewhat "invasive" to implement, there's quite a bit of unrelated changes that could be removed from this PR. Two more remarks that are not directly about your PR, but may influence your future contribution:
|
|
@SillyFreak Thanks for your initial review! I agree with most of your comments -- clearly I have marked it as a draft since I myself consider the PR needs improvements, and your feedback was required.
That's just to disambiguate the new development version from the released one.
I will try to pay more attention to what is internal/public.
I can completely revert it, but it is also quite logical that for multiple bibliographies one would like to have more control over how the title is rendered, e.g. whether these titles should always be at the first level.
I tried to keep all public identifiers kebab case and use snake case for the internal ones, but I can make internal ones kebab-case too.
I agree. I can add
I think prefixes have the same goal as biblatex categories (
It would be great if Typst naturally supports it and have biblatex feature parity. When I did my research few months ago, I have not seen these discussions.
I can move them to a separate PR: when I was first reading it, it was not clear for me that
Again, I can move it into a separate PR, but that classes' and fields' renames were meant to more closely follow the hayagriva names (and the field names in alexandria itself). |
Yes, I've seen platforms where the conventions are different. I don't think Typst as a whole has clear conventions, but my own are: only bump the version on release, since that is when you can be sure which version number should be bumped.
I'd prefer to revert since I want to perfectly mirror the built-in APIs wherever possible, and
May convention is to use kebab-case for all Typst identifiers. If there are exported but logically internal identifiers, I'd prefix them with an underscore (e.g. (I probably should put some of that in a contributions document, so that people can refer to it from the start)
I think the Hayagriva side is not that bad actually: you have a driver that you add citation requests to (e.g. all references for a full bib here), and if you filter that first, you have categories. Custom numbering and sorting is a bit harder this way, though.
Yes, this is very recent, last month. See here if you're interested: https://discord.com/channels/1054443721975922748/1246016569323159584/1383386231370420276
Yes please. Doc improvements are always welcome, and I unfortunately can't look at docs of my own package with an unbiased eye. It's just that in this PR, it distracts from the rest of the changes.
Agreed; that struct probably predates me building a more complete mental model of the Hayagriva side. Re the immediate future of this PR:
I don't know the exact timeline. If my time this summer permits I would like to help in the implementation myself, but I also can't make any guarantees. I think it would make sense to try and describe the desired API in detail first, so that even if Typst still takes a while, Alexandria has a better chance to go in the direction Typst will eventually take. I like what I see in the manual though; I think this could be broadly the way to go. |
|
fyi, I have written down some design notes here and also shared them with the Typst team to see if that is a direction they consider promising: https://typst.app/project/rOOEGr1WPuYxg25tAkEz09 This design does not use prefixes, but I think the I'd be interested in your thoughts, including whether you see anything that is impossible or less convenient with that design. |
Fixes #15.
The limitation of the current Alexandria approach is that bibliography lists are limited to a single prefix:
the splitting of the bibliography discussed in the example is by the reference type, not by the prefix.
This PR allows more flexibility:
alexandria-prefix()allows setting the default prefix).load-bibliography()is replaced by thecollect-citations(id, prefix-filter: ...)which allows creating lists of citations and references with mixed prefixes.render-bibliography()is simplified: instead of requiring the user to manually compose the filtered list of references,it accepts the ID of the bibliography list created by
collect-citations(),and allows further filtering by prefixes/details with the user-specific
filter: ref => boolfunction.The regression is that
fullis not supported (since the list is assembled from multiple prefixes).The manual and the examples are updated.
Unfortunately, it turned out to be much more invasive that I have anticipated, but I hope it can be useful.
Also, it's my first experience of writing something in Typst (and in Rust) :)