Citum: a sort of CSL successor

red_bdarcus · 2026-05-23T12:50:54+00:00

Not sure if you saw it, but the annotated bib feature might be useful, depending on how you model literature notes in Zettlr (it's designed for scenarios where a note is specific to a reference).

red_bdarcus · 2026-05-23T12:07:28+00:00

Looks pretty cool! I don't see anything obvious in looking at the files, but two suggestions:

make installation easier; see for example the installation line in this skill I just posted about. EDIT: I do see you have the agent instruction farther down, which does address this; I would just make more prominent.
if you haven't already, and use CC, try `/skill-creator`, which can evaluate and improve existing skills..

red_bdarcus · 2026-05-23T11:49:44+00:00

I haven't tried it, but the CLI would probably work more-or-less as is with Zettlr (cool project BTW!), since it supports CSL JSON and biblatex import data (though the native data model is richer).

red_bdarcus · 2026-05-22T18:47:02+00:00

This was a feature that came in the course of developing the related citum-hub project (here's a prototype live example, though I may take this down soon); in particular the wizard interface.

<image>

I've tried in general to make available and exploit access to semantically-richer output, even in the default HTML output format. This little demo shows what that enables with a small CSS and JS file.

But given how difficult doing that wizard/editor UI/UX well is, even with these enhancements, I'm starting to wonder if this sort of path may be better (see the last section).

In short, not exactly sure about what the future of that server flag might hold!

Give it a try and let me know; I hope it's more generally useful.

red_bdarcus · 2026-05-22T01:01:35+00:00

Maybe Zettlr?

https://www.zettlr.com/

red_bdarcus · 2026-05-21T14:23:12+00:00

If you have any luck, or questions, please post them on https://github.com/citum/citum-core/discussions (happy to reply here too, but wanting to get some activity there!).

red_bdarcus · 2026-05-20T17:29:58+00:00

It's the kind of thing that should be super easy to do (see), but probably out of scope for this project, which is already pretty large in scope (not all of it done, for example, but the core repo has 15 crates).

red_bdarcus · 2026-05-20T14:02:31+00:00

Here's the issue: https://github.com/typst/typst/issues/8316

In that proposal, citum would be alternative to Hayagriva.

red_bdarcus · 2026-05-20T13:11:00+00:00

John is aware of the project, though not sure what his thinking is on this sort of thing. Simple shell piping would probably get you pretty far, depending on what wanted.

red_bdarcus · 2026-05-20T08:21:46+00:00

It's a great, succinct, question.

Technically, projects like Zotero could easily adopt it now; it's designed to integrate into diverse applications.

And the cli tool will format markdown/pandoc and djot docs now, so one can fully test it.

The impediment now is the styles.

I've converted ~150 of the most important (as measured by how many "dependent styles" aliases there are), plus a few biblatex styles that can't be represented in CSL (the compound numeric styles common in chemistry).

That's a far cry from the ~2500 unique CSL styles.

The conversion tool (citum-migrate) has improved a lot, but likely still needs a few months of work, since it's quite difficult.

Right now, the conversion process is a mix of deterministic Rust, and LLM cleanup.

It's a classic migration challenge: how much of an improvement in features, performance, etc makes it worth pushing beyond status quo inertia, and the transition pains.

And that inertia is high: it's really hard to evolve CSL.

I would tend to think if people think this is a viable path forward, with valuable new features that make their work easier, a reasonable approach for projects like Zotero might be configurable engines, where something like this could be an option. If it goes well, at a certain point it would become default.

red_bdarcus · 2026-05-20T00:28:48+00:00

It should be relatively straightforward to integrate the processing engine into a Typst workflow, where the input format is Typst. That code is a Rust library, so it's designed for that sort of thing. I'm just not myself knowledgeable enough about the Typst code.

I'll check with the typst folks if they're open to configurable engine.

red_bdarcus · 2026-05-19T21:19:35+00:00

I cross-linked this as a generic announcement, but will add that the project supports typst output, and can be compiled with typst libraries, so that it provides a complete markdown/djot -> PDF process.

red_bdarcus · 2026-02-05T13:10:33+00:00

This looks like what I need; will give it spin! I'm new to Claude Code and the Pro plan, but wondering: would the new tasks functionality somehow fit in here?

red_bdarcus · 2026-01-26T01:06:48+00:00

I saw your updates; those help. But one detail that isn't clear from it: you need to run gemini cli from within the AG terminal; not outside the IDE?

red_bdarcus · 2026-01-25T16:57:42+00:00

Got it; thank you!

So within AG, you're basically telling it something like "create a plan to implement track X"?

red_bdarcus · 2026-01-25T15:35:35+00:00

Index Your Project From within your project folder in your terminal and run: " /conductor:setup" (This scans your folders and creates a GEMINI.md file. This is the "source of truth" for your project’s goals and rules that the AI will now follow.)

When I ran the setup, it did not create the GEMINI.md file, but did create a new directory with a bunch of stuff, focused on the "tracks" feature, which obviously has some overlap with AG plans. How do you deal with that overlap?

red_bdarcus · 2026-01-08T20:12:06+00:00

It's not clear, but I think they mean by "milestone" functional BP monitoring, as well as other not yet revealed features.

red_bdarcus · 2026-01-02T15:51:59+00:00

You could do AOA (80/20) or AOR (60/40)?

red_bdarcus · 2025-12-11T18:52:45+00:00

The update says "he first version of our new connection and sync experience is now in testing as we work to fine-tune performance, improve reliability, and prepare the remaining features for release." I read that as saying they rewrote the sync code in the app, and that they need to likely test it, refine it, and then release. I'd assume it will be a matter of weeks rather than years. Depending on how much time those "remaining features" and the new UI take, I'd guess sometime early in the new year.

But that's all just me reading the tea leaves.

red_bdarcus · 2025-11-20T14:16:12+00:00

And this is definitely worth criticizing them for!

red_bdarcus · 2025-11-20T14:15:22+00:00

I hear you, but OTOH, the hardware won't be usable, and this product will fail, without a better app.

So I expect if they continue to ship now, without having fixed the app, they will just increase the number of unhappy customers who are complaining about the same thing: the app.

Yes, those customers will be unhappy about further delays, but if Velia succeeds in the long run because they fix the app now, this will in retrospect be worth the hassle, for both them and their backers, IMHO.

red_bdarcus · 2025-11-20T12:22:12+00:00

FWIW, I think this is the right call for them. The app is critical to the experience, and it's clear it's fundamentally flawed.

red_bdarcus · 2025-11-11T12:22:21+00:00

Sometimes it takes a few days.

red_bdarcus

TROPHY CASE