u/d20frosted

Plain version first, since "schema" sounds heavier than it is: it's a way to write down what a kind of note should contain (which fields, of what type, which are required) and then check your notes against that. If you keep notes as structured data (wines, books, people, projects), it's a nudge to keep them filled in and consistent, and a fast way to find the ones that have drifted.

When I announced vulpea v2.4 here recently, the comments shaped the schema feature more than my own roadmap did, so first: thank you. This is the follow-up, and honestly a request for more of the same.

The short version. vulpea now lets you write down what a class of notes should look like, a predicate plus typed fields, with composition (:include), conditional rules, and reference checks (a link field can require its target to carry specific tags), then validate notes against it. And it grew a UI in vulpea-ui: a per-note health widget, in-buffer flymake linting, and a collection-wide dashboard with one-key fixes. I pointed the dashboard at my wine notes and it cheerfully told me 176 of 3,531 were broken, humbling, but for the first time fixable without leaving the buffer.

Full write-up, with screenshots and a dashboard demo: Vulpea schemas: structure you can see and fix

What I'd genuinely love feedback on, before I cut releases across the ecosystem:

• I have basically one serious use-case (wine, obviously). What would you use schemas for? Does the model fit the way you actually structure notes?
• Anything awkward or missing, in the engine or the UI? I want to use it for real and polish based on that before tagging.

Thanks again to everyone who chimed in last round, that engagement is the best part of doing this in the open.

i'm not very socially active, but every now and then i get reminded that reddit exists, and it's honestly a good place for this. we do have updates to share, and people clearly engage with the vulpea ecosystem, so consider this the little i owe you 🙂

quick context for anyone new: vulpea is a small library that gives org-mode a proper database layer. it stays minimal on purpose, the idea is you build your own note workflow on top of it rather than adopting someone else's.

v2.4 landed recently and it's a chunky one. three things i'm happy with:

unlinked mentions. surfaces notes that reference each other in plain prose but were never actually linked. it filters the obvious false positives (a note's own title, metadata) so you get real candidates instead of noise.

note schemas. you can declare what a note type should look like (say, a "wine" note must have a producer) and get back a detailed list of what's violating it, conditional rules included. useful when your notes drift over time.

rename with link propagation. vulpea-propagate-title-change renames a note and updates the incoming link descriptions to match, with a dry-run so you can preview before anything changes.

smaller stuff: bulk tag/meta ops, hierarchical tag queries, a vulpea-doctor diagnostic, stale-note detection, encrypted notes (.org.age / .org.gpg), and a ready-made doom module.

one quality-of-life fix i should've shipped ages ago: the db now auto-rebuilds on schema changes, so upgrades don't blow up with column-mismatch errors anymore 🤦‍♂️

full writeup with examples: https://www.d12frosted.io/posts/2026-06-19-vulpea-v2-4 full changelog: https://github.com/d12frosted/vulpea/blob/master/CHANGELOG.org

happy to answer anything, and always curious how people are actually using it 🙂

The initial release got shared here a while back as a bare link with no description, which is a bold move for a UI library that also happened to ship with zero screenshots. Let me fix both of those.

vui.el is a declarative, component-based UI framework for Emacs. If you have used React the model will feel familiar: you define components as functions of state and props, compose them into a tree, and the library handles efficient updates through reconciliation. It is built on top of widget.el, so the buttons, fields, and keyboard navigation are the real thing, not a reimplementation.

The GIF up top is the CI pipeline dashboard example - coloured status, live per-row progress bars, a Retry button, a timer advancing jobs, all from declarative components reacting to state (and remember: tab allows to jump between interactive widgets). And here is the whole model behind it. A counter is about this much code:

(vui-defcomponent counter ()
  :state ((count 0))
  :render
  (vui-fragment
   (vui-text (format "Count: %d" count))
   (vui-newline)
   (vui-button "Increment"
               :on-click (lambda () (vui-set-state :count (1+ count))))))

(vui-mount (vui-component 'counter) "*counter*")

which gives you a buffer with (screenshot would be boring):

    Count: 0
    [Increment]

and each click bumps the number and re-renders. State in, vnodes out, the library diffs and patches the buffer. The dashboard up top is just more of the same.

You get local state and props, lifecycle hooks, the usual hooks (use-effect, use-ref, use-memo, use-callback, use-async), context, error boundaries, and layout primitives (hstack, vstack, flex, box, table, list).

What is new in v1.2: inline mounting (components into a region at point in any buffer, for ephemeral in-document forms), vui-flex (width-distributing rows), container styling (face/keymap on whole containers, themable table faces).

The part I am happiest about is that it is not just my own packages using it anymore: ekg and emacs-bluesky (ahyatt), beads.el (ChristianTietze + r0man), gastown.el (r0man), unicode-inspector.el / eijiro-search.el (zonuexe), plus my own vulpea-ui, vulpea-journal, brb.

More information here: https://github.com/d12frosted/vui.el

Feedback and questions welcome. Screenshots included this time.