It was my first week officially at the Bibliotheca Hertziana in Rome, which meant that I was shown the ropes. I submitted to a security tour on Wednesday and a library tour on Thursday. The institute is headquartered in the 16th century Palazzo Zuccari at the head of the Spanish Steps, and smokes into Palazzo Stroganoff (one building back) and Villino Stroganoff (the main garden and conference venue across the road). More recently, in 2013, a new building known as the Neubau was constructed over what used to be the garden between Zuccari and Stroganoff. The Neubau is, somewhat incredibly, fully suspended, as the remains of a 60 BC villa beneath the palaces ruled out a more regular foundation, or at least one with legal and archaeological legitimacy.
I also began to learn more about the work of my colleagues in the MVC group, and I look forward to deepening my appreciation here in the coming four months. My fellowship runs through to the end of 2026.
This platform went into beta testing this week, so I’m looking forward to getting feedback and (very soon!) releasing it. New data surfaced that we’re aiming to incorporate before that release, but I’m hopeful that it won’t cause too much of a delay, maybe only a week or two.
As the semester comes into its own, a few cycles were spent thinking in this space again. There are two separate seminars at the Lab, on Cassirer and Lyotard, and it may be that we can incorporate some of this conceptual work into the more empirical character of the paper-in-progress.
A good heap of refinements to rookery were piled up this week! These include improvements to the pinboard package, such as click-and-drag to multi-select ideas and nicer UI for the selected state. I also firmed up the ideate workflow, which will be one of the main ways that I file ideas going forward. I am now writing these weeknotes, for example, as a normal text file with a #show: weeknote.with(year: 2026, week: 38) header, where weeknote is a Typst template that wraps #ideate to parcel out each section as its own idea.
I spent a long weekend hacking on Saturday and Sunday, reshaping the @rookery/core API and improving the documentation so that it documents the full range of public functions. I’m proud enough of the current API’s elegance and the state of the documentation that I released a 0.1.0 of the core package and announced the project on socials. (Pulling this together is part of the reason that I’m posting this weeknote on Tuesday again, as I released the project midday Monday.)
Only a few components of the Rheo/rookery ecosystem are still missing, I think, before it provides an experience comparable to other modern dev tools, such as a language server extension for Rheo (for errors and autocomplete in editors), and some performance improvements for incremental recompilation of large rookeries (>100 ideas). If you’re so inclined, please do try it out and open an issue if the experience isn’t what you expect.
A good experience of building out rookeries relies heavily on Rheo, the engine that pulls in the rookery package, compiles it to HTML, and incrementally rebuilds the site on changes to source files. I packaged this week’s changes into a 0.6.4 release, as they mostly pertain to better incremental compilation and code quality.
Taking a cue from Kento Okura’s development of Forester 6.0 (via Jon Sterling’s weeknote section on it), I added support for Idiomorph to the Rheo watch server. Typst has built-in incremental compilation so that the compiler doesn’t have to recompute everything every time you add content to a source file, and instead only does the necessary work to recreate the PDF or HTML file. But without Idiomorph, that incrementality wasn’t felt in the downstream browser, as the watch server would refresh the entire page once the new HTML file was ready. Now, the browser gets only the little package of content that has changed and inserts it into the DOM at the appropriate place. This may seem subtle, but it matters a great deal when editing files in a rookery, as it means that your state (scroll position, input text, and so on) is maintained while you’re working on the underlying files.
@rheo/rehydrateFollowing on from this change, I added a @rheo/rehydrate package to rheo-packages. This is an opt-in optimization that Rheo package authors can use to ensure optimal rehydration in Rheo watch dev servers. The bottom line here is that Rheo doesn’t analyze JavaScript code in packages to understand whether or not they need to be re-run when HTML elements in the page are inserted or changed (as happens when a Typst source file incrementally recompiles). Packages need to alert Rheo how to run package JavaScript when a change occurs. Currently, this alert takes the form of a coarse-grained js_rehydrate boolean, which tells Rheo to re-run package JavaScript on every change when true. @rheo/rehydrate may become more nuanced in the future as Rheo’s incremental compilation and package system evolve.
@rheo/sitemap and other improvementsI consolidated blogfeed and sidebar into a single sitemap package, as they both offer UX elements that are projections of Rheo’s spine. There are a few smaller improvements in the release, such as fixing a package conflict in a local cache when you use both the releases and repo attributes in different Rheo projects on the same machine, so that you can maintain different versions of custom packages across different repos. Thanks also to Luigi Sartor Piucco for the fix to Rheo’s Nix flake.
I also began migrating papers that were previously standalone Rheo projects into waterline. I want to do this so that I can do all of my writing within the context of my main rookery, even if that writing is intended for a downstream context such as a sub-rookery (like my blog site or these weeknotes) or a paper submission.
It also means the #cfp declarations that I use to track submissions to conferences, jobs, and journals can reference the writing I submitted at each stage directly, since all of that writing is structured as an idea or a set of ideas. In this way, ideas as abstract units are a step towards an ideal writing system, as they improve the portability of bits of writing between different contexts (blog posts, published papers, meeting notes, and so on).
Any idea or folder of ideas can be excised as its own sub-rookery using an additional rheo.toml file. As such, both this weeknotes site and my main blog site are now sub-rookeries that are versioned in waterline, which is my writing mono-repo. I’ve set up a separate CD process for each subdomain I want, each with its own Rheo command. To build my weeknotes rather than all of waterline, for example, I run:
rheo compile waterline \
--config "weeknotes/site.toml" \
--build-dir "weeknotes/build" \
--htmlI’m pretty happy with this setup, and I’ve started migrating the rest of my active writing projects—a few papers in flight, and the small matter of my dissertation—into waterline in the same manner.
A substantial amount of work on birds this week, which I’ve decided will be the topic of the fifth chapter of my dissertation. If Rheo and rookery are my contribution to writing and publishing software, birds is my contribution to agential programming. I drafted the documentation for birds (as a rookery, of course), and filed various fixes and improvements as I worked on changes to Rheo and rookery. Birds has fully replaced beads and abacus for me now, but it’s still in early-stage development. The agential programming space is moving so fast these days that I want to wait a couple more months before claiming birds is a durable contribution, which at AI speed amounts to years, as they say.