Highlighter adapter product#15
Merged
Merged
Conversation
- New optional MarkdownEngineHighlighter product ships HighlighterSwiftBridge, a turnkey SyntaxHighlighter backed by HighlighterSwift. Core MarkdownEngine stays HighlighterSwift-free at link time. - Make NativeTextViewWrapper init params optional with sensible defaults so the minimal usage is NativeTextViewWrapper(text: $text). Demo simplified accordingly. - Parameterize CodeBlockButton with topInset/trailingInset (defaults 6/8 keep the button inside the code block). Callers wanting the legacy gutter look pass trailingInset: -25. - Fire updateCodeBlockSelection on frameDidChange so copy-button positions follow window resizes, not just scrolls. - Have LayoutBridge.boundingRect ensureLayout for the prefix range before measuring, eliminating the initial Y-jump that occurred when text-delegate callbacks fired before TextKit 2's layout pass had converged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Merged Theme, Tuning, Wiki-Link state, Custom Services, and Syntax Highlighting into one Customization H2 with H3s — they were previously five top-level peers which made the README feel highlighter-focused and over-engineered. Installation product table collapsed to a single sentence; protocol implementation walkthroughs deferred to DocC. 303 → 244 lines, 18 → 12 H2 sections. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The two-row table is more scannable than prose for a "what's in the package" overview — keeping it alongside the descriptive paragraph that links into Customization. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Three structural cleanups from comparing the layout against snapshot-testing, MarkdownUI, HighlightedTextEditor, and Runestone: - Removed the standalone "Architecture" H2 that sat between Features and Installation. Its protocol table is now part of Customization → Custom Services, where it belongs. Reader hits Quick Start ~10 lines sooner. - Merged "Requirements" + "Status" into one H2 — both were 2–3 lines and reading two adjacent ultra-short H2s felt like filler. - Dropped the "no-op services" restatement from the Quick Start paragraph; it's now stated once, in Custom Services. 244 → 232 lines, 12 → 10 H2 sections. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two structural fixes: - Move "Service Protocols" (renamed from "Custom Services") to the front of Customization, before any specific protocol implementation example. The previous order introduced `SyntaxHighlighter` and similar terms in the Syntax Highlighting section before the four-protocol architecture was established. - Demote "Wiki-Links & Replacement State" to the end of the section — it's a wrapper-binding feature, structurally different from the config-based customizations around it. Also: explicitly call out HighlighterSwiftBridge as the recommended path in Syntax Highlighting, with concrete reasons (line-height metrics, appearance switching, layout timing) why rolling your own SyntaxHighlighter is footgun-heavy. Empirically validated in this branch's own bring-up. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Previously the last column mixed defaults, bundled bridges, and suggested libraries into one cell. Splitting them makes it scannable at a glance: default class, ready-made bridge (with the library it wraps), or the suggested library plus "roll your own" hint. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- Default column is redundant with the intro line "each with a no-op default" - "wrapping HighlighterSwift" → "built on HighlighterSwift" (less jargony) - "roll your own bridge" → "build your own adapter" Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The earlier prefix-ensureLayout on every viewRect call made boundingRect the perf bottleneck on large documents — every keystroke triggered N layout passes (one per visible code block). Replace with two narrow guards: - One-shot ensureLayout per document via a flag on the coordinator (`didEnsureLayoutForCurrentDocument`). Reset on document switch and on real viewport width changes (which invalidate TextKit's wrap layout). - frameDidChange now refreshes code-block overlays only when viewport width actually changes, filtering out TextKit's frequent height-only echoes during typing. Net result: zero per-keystroke ensureLayout cost, correct geometry on fresh load, and overlays follow window-width drags. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Replaces the CSS-theme-driven defaults with opaque code-block backgrounds (calibratedWhite 0.95 / 0.13) and an SF Mono → Menlo → system-monospace font chain — the same look Xcode, GitHub, and VS Code use. Also pin appearance to the editor's window rather than NSApp so apps that force a light window in dark mode still tint code blocks correctly. All three new defaults are init parameters; pass `nil` for the backgrounds or a custom `preferredFontNames` array to opt back into CSS-theme-driven appearance. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Mirrors the original CodeHighlightService caching used in Nodes: NSCache<code, NSAttributedString> with countLimit 256 / totalCostLimit 2MB, plus a parallel failed-highlight cache and an unsupportedLanguages set so a language Highlighter can't recognize by name falls back to auto-detect on first attempt and stays auto-detected after. Cache is busted on theme switch via applyAppearanceTheme. Without this every keystroke re-highlighted every visible code block through HighlighterSwift's JavaScriptCore bridge — the dominant per-keystroke cost in documents with non-trivial code-block density. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.