Things become duplicated in Tlön; they also tend to become effaced and lose their details when they are forgotten. A classic example is the doorway which survived so long as it was visited by a beggar and disappeared at his death. At times some birds, a horse, have saved the ruins of an amphitheater.
- Jorge Luis Borges, Tlön, Uqbar, Orbis Tertius

description

kishin is the small static site generator used to generate this site. It accepts more-or-less plain html as its input and handles the basic site templating, backlinks generation, and tag management.

It is written in C as an exercise in learning the basics of the language, and currently has two dependencies: tree-sitter and tree-sitter-html. These libraries are used for parsing and generating easily navigable syntax trees.

I hope to improve this generator over a period of time -- not only in terms of features, but also in terms of C code quality and conventions.

devlog

2026-02-01

• i'm starting to get tired of having to hit a bunch of keystrokes in my text editor to get my static site regenerated. it would be nice to have something that detects relevant changes and automatically re-runs the static site generator.
• i think my solution (at least for now) will be to use entr. a nice side benefit is that entr is a relatively simple program written in C, so it's a great opportunity for me to dig into the code myself and learn about good C programming style/conventions.
• the project currently statically links against tree-sitter and tree-sitter-html. this causes problems when moving between my macbook (couch) and my linux desktop (desk), as the .a libraries built on linux don't seem to work on mac and vice versa. maybe i should just dynamically link instead? i'm under no illusions that this site generator is gonna be small and self-contained anyway, as i'd ideally like to have some latex and syntax highlighting support. for the former seems to require katex (node.js), not sure about the latter (it could be a non-trivial project for myself to use tree-sitter to do this, given some sort of color scheme data).
• incidentally, i was trying to understand the basics of compiling, linking, libraries, etc. and i found these notes to be a good overview. hoping to find a C or unix book that explains these things in more detail. of course, there's always the man pages.

2026-01-31

• put in my first code block and realized how annoying pre-formatted text in html is...

2026-01-29

• gave up on the idea of tags for now. i think the website will be a jumbled mess of flatness and hierarchy for now. whatever
• started working more seriously on the initial content

2026-01-27

forgot this devlog existed for a bit, as i've been working on this in fits and starts. so this is multiple days of work.

• refactored code to first parse input pages into data structures and then afterwards write all out at once. this allows for modifications such as replacing broken internal links with links to the 404 page, and keeping track of backlinks for the backlinks to be rendered in one pass during the write-out phase
• moved away from a hierarchical system and moved the h1 to the nav
• implemented a link replacement layer: internal broken links are changed to 404.html. this was a fairly interesting problem -- we use treesitter's ability to edit nodes and then modify the existing tree incrementally (and any already existing other independent nodes) without having to re-parse a whole new tree.
• started tracking backlinks. the 404 page is slightly exceptional in that it records not the page that directs to it but instead the page that is missing. setting this up was easier than i expected, さすが refactoring さん. one thing to still do is to replace the display texts for the backlinks to the title, maybe, instead of the filename, which may be less informative or even not designed for human readability
• haven't gotten around to the tag system yet. but once the backlinks are done, i think we're almost in a deployable state. obviously the content needs to catch up.
• ...or maybe not. maybe the notes section won't make any sense until a tagging system is done?

2026-01-16

• started thinking about the backlinks, tagging, and 404 link system
• considered moving the h1 tag to the nav, but the code is currently not written in a way to make this easy... currently parsing logic is interwoven with calls to fputs. it may be wise to parse through, extracting all data into a struct, and then write all in one go. this might also reduce the need for multiple passes for the backlinks, etc.
• i do really like the hierarchical navigation that xxiivv and nchrs use, but i'm not really sure i want to constrain my pages in that fashion. i think i prefer (for now) to use a flat structure with tags. in this case, it may make sense to use the navbar to display the h1-level title, and leave all navigation (backlinks, tags) towards the bottom. another option would be to display the tags or backlinks in the navbar (in some fashion). this is probably too much to show before the main content, though.

~