TODO

Markdown syntax deliberately left unimplemented, from the Markdown Guide cheat sheet. Everything else on that page (headings H1–H6, bold/italic, blockquotes, ordered/unordered lists, inline code, horizontal rules, links, fenced code blocks with a language tag, strikethrough, task lists, highlight, subscript, superscript, and automatic URL linking) is implemented.

The items below don't fit hush's current architecture (a flat list of blocks, each holding one line of text, styled via inline "runs" over that text) without a genuinely new subsystem, not just a new block/run type. Rough notes on what each would take:

• Tables. The document model is one line of text per block; a table is a 2D grid of cells,

  each with its own inline-formatted content. Needs either a new block type whose text holds the whole raw table (parsed and laid out as a grid at render time) or a run of dedicated row/cell blocks — plus actual column-width computation and a grid layout in render.c (no precedent for multi-column layout there today).

• Real images. ![alt](url) is currently no different from a plain paragraph line (falls

  through markdown_io's parser as literal text) — there's no image loading/caching/rendering path anywhere in the codebase. Needs texture loading from disk (raylib supports it, but nothing here does it yet), cache invalidation when a document is closed, and a render path that isn't just measured text (images don't word-wrap).

• Footnotes. [^1] inline + [^1]: text definitions. Semantically these aren't inline

  document order — a footnote definition is meant to be collected and rendered as an endnote, which means a document-wide pass to gather definitions before rendering, not just a new block/run type. The inline marker also needs to visually link to its endnote (superscript number), which layers on top of the superscript work already done here.

• Definition lists. Term\n: Definition — the current model has no notion of "this block is

  associated with the previous one" (unlike numbered-list renumbering, which only counts consecutive same-type blocks, it doesn't pair distinct types together). Would need a new paired-block concept from scratch.

• Heading IDs. ### Heading {#custom-id} — parseable cheaply (strip a trailing {#...}

  from the heading's text on load), but pointless without something to link to an ID — hush has no internal anchor-link/navigation feature at all, so this only becomes worth adding alongside real link-following.

• Emoji shortcodes. :joy: → 😀. Needs a shortcode→codepoint lookup table (not hard) and

  a font with real emoji coverage — the bundled DejaVu fonts only load ASCII + Latin-1 + a handful of individually-added symbol codepoints (see fonts.c), nowhere near emoji range. Would mean bundling a color/monochrome emoji font and wiring a second font source into the glyph-loading path.