Open code files with syntax highlighting and LSP navigation

[nonatofabio]

Summary

Let Mindle open code files, not just Markdown — with syntax highlighting and LSP-powered navigation (go-to-definition, find-references, hover) so you can move through source the way you move through prose. Agents write far more code than they write prose; when an agent produces a doc plus the code it documents, you currently have to bounce to an IDE to read the code. Opening code in Mindle keeps the whole review in one calm surface and extends the existing "AI writes, you read, you mark up" loop to source files.

Proposed behavior

Viewing

• Syntax highlighting rendered through the existing WKWebView HTML pipeline (vendor a JS highlighter into Resources/web/vendor/ alongside Mermaid/KaTeX).
• Detect by extension first; fall back to content sniffing for extensionless files (same approach as the JSON/YAML request, Render JSON, JSONL, and YAML files with pretty/expandable view #8).
• Reuse existing reader chrome — tabs, themes, sidebar file tree, Quick Look.

Navigation (LSP)

• Go-to-definition, find-references, hover/symbol info — reading affordances only.
• One language to start (e.g. Swift via SourceKit-LSP, or TS via typescript-language-server) to prove the mechanism end-to-end before generalizing.
• Launch a language server already on the system (no bundled toolchains); friendly inline error when the server isn't found — same philosophy as the "Mindle isn't running" MCP error.
• Resolve workspace root from the opened file upward (nearest Package.swift / tsconfig.json / .git); degrade to highlighting-only in single-file mode.
• No completions, no diagnostics-as-you-type, no refactors — those are authoring features, out of scope for a reader.

Editing — diff-review only, NOT a code editor

The only mutation path is the existing diff-as-editor surface extended to code: when an agent changes a tracked code file, Mindle renders the track-changes diff and you accept / reject chunks. You never type code directly — same discipline as the Markdown reader. The diff render just needs to preserve highlighting inside insert/delete spans. Annotations + MCP also extend for free: mark up a code passage with a directive, the agent reads it back via get_annotations and clears it with a summary.

Why this fits Mindle

The annotation + diff + file-watch machinery is file-type-agnostic in principle — a code file is "just another file the agent writes." Reviewing agent-written code alongside its Markdown docs, without launching VSCode, is the same workflow #8 describes for JSON/YAML, one step further.

Positioning note

This is the biggest expansion of Mindle's reader-only identity to date. The discipline that keeps it honest: code is read + diff-review only, never free-typed, so the product stays "you read, you mark up, the agent does the writing." If that line ever blurs toward a real code editor, it should be reframed as a deliberate separate phase (the roadmap already flags this for editing in general).

Implementation notes (optional)

• Highlighter: bench Shiki (TextMate-grade, heavier, async) vs. highlight.js (lighter, coarser) on realistic source files before vendoring.
• LSP transport: launch the server as a subprocess, speak JSON-RPC over stdio; a thin Swift LSP client bridges editor positions ↔ document URIs. Results render in existing surfaces — hover as a popover, references as a list, go-to-def opens/jumps the target in a tab.
• Open questions: Swift-first (dogfood Mindle's own codebase) vs. TS-first (largest agent-output surface)? Do code annotations need line-anchored vs. text-range anchoring? Go-to-def across files — new tab or in-place nav with a back stack?

Smallest first step

Syntax-highlighting-only code viewing for one language, no LSP. It reuses the existing render pipeline, is independently useful, and de-risks the workspace/transport work before any language-server process is involved. LSP navigation lands as a fast-follow once a code file renders cleanly and the diff surface handles highlighted spans.