bitwize-ai/Logue

Summary Every block in the document editor reports its frame through a SwiftUI preference on every layout pass. Because the frames are measured in the scroll coordinate space, all of them change on every frame of a scroll, so the cost of this bookkeeping grows with document length even though the frames are only ever read during a cross-block drag. Collecting them only while a drag is in progress would make scrolling cost independent of document size. This is a follow-up to the scroll-performance fix that moved these frames out of observed view state. That change removed the expensive part — a full editor body rebuild per scrolled frame — but deliberately left the collection itself untouched to keep the diff small. This issue covers the remainder. Background Each row publishes its frame via a GeometryReader in a .background: Logue/Views/Editor/BlockEditor/Views/BlockEditorView.swift:6 — BlockFramePreferenceKey Logue/Views/Editor/BlockEditor/Views/BlockEditorView.swift:93-99 —

Context BlockSerializer converts between markdown text and the editor's block model, in both directions. It's the single most correctness-critical piece of the editor: a round-trip bug means silent data loss — someone's content changes shape when they reopen a document. Coverage today is example-based (specific inputs, specific expected outputs). What's missing is the general property: For any valid document, parse(serialize(blocks)) should produce blocks equivalent to the originals. Why this is a good first issue No UI work, no AppKit, no SwiftUI. Pure model-level testing — a genuinely good way to learn the codebase. And it will very likely find real bugs, which is the point. What to do Add a test suite that generates a variety of block arrays, serializes them, re-parses, and asserts equivalence. Acceptance criteria A new suite in LogueTests/ covering every Block case: paragraph, heading (all 6 levels), bullet/numbered/checkbox lists (including nested indent levels), block quo

Context In a long document there's no way to fold a section away. Collapsing content under a heading makes restructuring and reviewing much easier. What to do Let a heading collapse the blocks beneath it, down to the next heading of the same or higher level. The hard constraint, and the point of this issue Fold state must never be written into the markdown file. It is presentation-only. Documents have to stay valid, portable markdown that other tools can read — adding private folding syntax would break that promise. So fold state lives in editor state keyed by block, not in the document model that gets serialized. Acceptance criteria A disclosure control beside a heading collapses and expands the section A keyboard shortcut does the same for the focused heading Collapsing hides every block until the next heading of the same or higher level (an H2 collapses following H3s; it stops at the next H2) The serialized markdown is byte-identical whether a section is collapsed or expanded

Context There's no in-app preview for files. Anything that isn't a document or a meeting has to be opened in an external app, which breaks the flow — and for a privacy-first app, handing files to another application isn't ideal either. macOS provides QLPreviewView (QuickLook), which handles PDFs, images, audio, and video with no third-party dependency. Nothing exists yet — this is greenfield and self-contained. What to do Add a reusable SwiftUI wrapper around QLPreviewView and use it to preview a file. Acceptance criteria A reusable NSViewRepresentable wrapper around QLPreviewView PDFs, common image formats, and common audio/video formats preview in-app An "Open in default app" fallback for anything QuickLook can't render A file that's missing or unreadable shows a clear message rather than an empty pane or a crash No force-unwrapping of URLs, and no try? swallowing errors silently — see CLAUDE.md Pointers Logue/Engine/DeckPDFExporter.swift and Logue/Services/PDFExportSer

Context Long documents are hard to navigate — there's no outline view. All the information needed is already in the block model: headings are case heading(id:level:text:). What to do Add a panel that lists the current document's headings and scrolls to one when clicked. Acceptance criteria A TOC panel is available in the editor's inspector area and can be toggled (a shortcut like Cmd+Shift+T would be welcome) It lists headings in document order, indented by level Clicking scrolls the editor to that heading The outline updates as headings are added, edited, or removed A document with no headings shows a helpful empty state, not a blank panel The panel stays responsive while typing in a long document Pointers Logue/Views/Components/HorizontalInspectorTabBar.swift — how inspector tabs are registered Logue/Views/Editor/BlockEditor/Views/BlockEditorView.swift — holds document.blocks, and already has a scroll-to-block mechanism (programmaticFocusTarget) you should reuse rather