feat(markdown): colour fenced code blocks

[matej21]

Problem

Open a .md file in the viewer and the two panes disagree with each other. The source view is fully highlighted; the rendered view next to it draws every fenced code block in one flat colour, whatever the fence says the language is.

Nothing about the rendered view justified the difference — the highlighter simply lived somewhere okena-markdown could not reach.

Why a crate move was needed

The syntect setup — the shared SyntaxSet, the dark/light theme pair, the per-line span builder — lived in okena-files, and okena-views-git reached into it for the diff viewer. But okena-files already depends on okena-markdown, so the markdown renderer could not depend back on it.

The alternatives were worse: a second syntect dependency inside okena-markdown means a second SyntaxSet in memory (megabytes, for a copy of data the process already holds), and injecting a highlighter callback from the app threads a hook through every caller for one feature.

okena-highlight now sits below both. syntax.rs and markdown_highlight.rs move across unchanged, build_styled_text_with_backgrounds moves out of code_view for the same reason, and okena-files re-exports all three — so every okena_files::syntax::… and code_view::build_styled_text_with_backgrounds import elsewhere is untouched.

Name: okena-highlight, not okena-syntax, because #188 is adding an okena-syntax for something else entirely (tree-sitter facts about code structure — symbols, calls, visibility; no colours). Checked: that branch does not touch the highlighting modules, so there is nothing to share between the two and nothing to take over from it.

What the markdown side does

Node::CodeBlock carries the spans for each of its lines, filled by MarkdownDocument::highlight_code_blocks(is_dark).

That is deliberately a separate step from parsing. Colours come from the syntax theme, and the parser has no business knowing whether the app is dark or light. The file viewer calls it after parsing, and again from update_config when the theme flips — the same place the source view re-highlights. A document that never gets the call renders exactly as it does today.

Two constraints that shaped the implementation

Spans must reproduce their line verbatim. Selection offsets are character counts into the raw code, so a span set that drops or rewrites characters silently shifts every selection on the line. This is why highlight_code_block does not expand tabs, unlike the file path which always has: four spaces where a tab was would move the selection. A test pins the invariant.

An unlabelled fence keeps the document's colour. Highlighting it as plain text would not leave it alone — it would repaint it in the syntax theme's foreground, which is a different colour from the document's. So a fence with no language, or one syntect cannot place, comes back with no spans at all and renders through the old path.

The one visible change to existing behaviour: a highlighted line is drawn as a single StyledText with the selection as a background run, instead of the three plain divs a selected line used to split into. Unhighlighted lines keep the old path.

Validation

• cargo check --workspace --all-targets, cargo clippy --workspace --all-targets, cargo fmt --all --check — clean
• cargo test — okena-markdown 13, okena-highlight 6, okena-files 63, okena-views-git 17, all passing
• New tests: spans reproduce each line verbatim (tabs included); unknown and missing fence languages stay unhighlighted
• Not done: no visual check in the running app. The colours and the StyledText-inside-a-styled-parent pattern are the diff viewer's, so this is low-risk, but somebody should still look at a rendered .md before merging.

🤖 Generated with Claude Code

https://claude.ai/code/session_01AWSp87PWoqnyB6prN3U3qD