Summary
Editor.SyntaxHighlighter types ISyntaxHighlighter and StyledSegment from Terminal.Gui.Drawing.Markdown. They were added to TG to drive MarkdownView rendering and happen to fit a general syntax-highlighting shape, but reusing them here couples the editor's general "code highlighting" feature to TG's Markdown subsystem in two awkward ways.
Why it's awkward
-
Discoverability. A consumer hooking up syntax highlighting on Editor doesn't expect to import Terminal.Gui.Drawing.Markdown. The types' XML doc also describes them in Markdown terms (segments of styled text within a Markdown document).
-
Ownership. If TG decides to reshape the Markdown highlighter (e.g., add Markdown-specific fields to StyledSegment, change the lifecycle expected by MarkdownView), they'll do it without considering Editor.
-
Spec deviation. specs/00-plan.md §6 prescribes a HighlightingColorizer : IVisualLineTransformer driven by an IHighlighter we lift from AvaloniaEdit's Highlighting/ folder. Today's wiring uses neither — it's a stopgap that pretends the Markdown contract is the editor's general highlighter API.
Options
- Define
Terminal.Gui.Editor.ISyntaxHighlighter ourselves. Same shape, our own contract. Adapter pattern at the boundary if a TG MarkdownSyntaxHighlighter instance gets passed in.
- Push the contract upstream into a TG-general namespace (e.g.,
Terminal.Gui.Drawing.Highlighting) so both MarkdownView and Editor can consume it without one referencing the other's namespace.
- Wait for the §6 lift. When
Highlighting/ is lifted from AvaloniaEdit (specs/00-plan.md Phase 6), the AvaloniaEdit IHighlighter becomes the canonical contract and the temporary ISyntaxHighlighter plumbing here gets replaced by IVisualLineTransformer + a colorizer. The current wiring is throw-away.
If (3) is the plan, mark Editor.SyntaxHighlighter [Obsolete] (or at least add a // TODO: replace with HighlightingColorizer when Phase 6 lands) so external code doesn't take a dependency on it.
Related
Summary
Editor.SyntaxHighlightertypesISyntaxHighlighterandStyledSegmentfromTerminal.Gui.Drawing.Markdown. They were added to TG to driveMarkdownViewrendering and happen to fit a general syntax-highlighting shape, but reusing them here couples the editor's general "code highlighting" feature to TG's Markdown subsystem in two awkward ways.Why it's awkward
Discoverability. A consumer hooking up syntax highlighting on
Editordoesn't expect to importTerminal.Gui.Drawing.Markdown. The types' XML doc also describes them in Markdown terms (segments of styled text within a Markdown document).Ownership. If TG decides to reshape the Markdown highlighter (e.g., add Markdown-specific fields to
StyledSegment, change the lifecycle expected byMarkdownView), they'll do it without considering Editor.Spec deviation.
specs/00-plan.md§6 prescribes aHighlightingColorizer : IVisualLineTransformerdriven by anIHighlighterwe lift from AvaloniaEdit'sHighlighting/folder. Today's wiring uses neither — it's a stopgap that pretends the Markdown contract is the editor's general highlighter API.Options
Terminal.Gui.Editor.ISyntaxHighlighterourselves. Same shape, our own contract. Adapter pattern at the boundary if a TGMarkdownSyntaxHighlighterinstance gets passed in.Terminal.Gui.Drawing.Highlighting) so bothMarkdownViewandEditorcan consume it without one referencing the other's namespace.Highlighting/is lifted from AvaloniaEdit (specs/00-plan.mdPhase 6), the AvaloniaEditIHighlighterbecomes the canonical contract and the temporaryISyntaxHighlighterplumbing here gets replaced byIVisualLineTransformer+ a colorizer. The current wiring is throw-away.If (3) is the plan, mark
Editor.SyntaxHighlighter[Obsolete](or at least add a// TODO: replace with HighlightingColorizer when Phase 6 lands) so external code doesn't take a dependency on it.Related
specs/00-plan.md§6 (rendering pipeline) and Phase 6 (Highlighting/lift).