memory: log in-app code-markup/editor-pane idea

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

memory.md

@@ -38,6 +38,7 @@ Durable memory for this project. Read at session start, update before session en
 - [x] ~~**M5 — Ship infrastructure.**~~ Custom icon, version bumped to 0.1.0, `scripts/release.sh` for one-shot tag+upload, README install section. Done 2026-05-22. **Next step (user action):** run `pnpm tauri build` on Windows then `scripts/release.sh v0.1.0` from WSL to cut the actual release.
 - [ ] **Native Windows shells (cmd / pwsh)?** `portable-pty` supports them for free; keep the option open. Decide whether to expose in UI at M3.
 - [ ] **Persistent scrollback across app restarts.** Would need an out-of-process mux daemon. Big scope creep; explicitly deferred past v1.
+- [ ] **Code markup / syntax highlighting in-app (VSCode-style).** User idea 2026-05-28 — "would be kind of neat." Two readings, different feasibility: (a) **highlight code in terminal output** — not really doable in xterm.js; it renders raw bytes/ANSI and has no concept of "this region is Python." Would need to detect code blocks and re-emit ANSI color, which is fragile and fights TUIs like claude that already color their own output. (b) **a dedicated editor/viewer pane type** alongside terminal panes — embed Monaco or CodeMirror as a new LeafNode kind, open a file from the pane's cwd, get real VSCode-grade highlighting + read/scroll (maybe edit). This is the tractable version: the layout tree already supports heterogeneous leaves, so it's "add a non-xterm pane kind" rather than reworking the renderer. Scope: pick editor lib (CodeMirror 6 is lighter than Monaco for an embed), file-open IPC over WSL paths, decide read-only vs editable. Defer — nice-to-have, not core to the multi-terminal purpose.
 - [ ] **Keybinding philosophy.** Copy tmux, copy WezTerm, or invent? Decide at M3.
 - [ ] **Help (?) overlay.** Small `?` icon in the titlebar, opens a modal listing all keyboard shortcuts (split / close / promote / broadcast / palette / font size / nav) and quick tips on shell-picker dropdown + SSH host manager + saved-password autotype. Same modal style as `Palette` / `HostManager`. Source of truth lives in one place — refactor the README shortcuts table to be generated from it (or vice versa) so they can't drift.
 - [ ] **MCP server: Claude controls tiletopia.** Expose a Model Context Protocol server (stdio transport, runs inside the Tauri app or a sidecar) so a Claude session — running anywhere, including inside one of tiletopia's own panes — can drive the workspace. Capabilities to expose as MCP tools / resources:

package.json

@@ -18,6 +18,7 @@
     "@tauri-apps/api": "^2.0.0",
     "@tauri-apps/plugin-clipboard-manager": "^2.0.0",
     "@tauri-apps/plugin-opener": "^2.0.0",
+    "@xterm/addon-canvas": "^0.7.0",
     "@xterm/addon-fit": "^0.10.0",
     "@xterm/addon-web-links": "^0.12.0",
     "@xterm/xterm": "^5.5.0",

src/components/XtermPane.tsx

@@ -2,6 +2,7 @@ import { useRef, useEffect } from "react";
 import { Terminal } from "@xterm/xterm";
 import { FitAddon } from "@xterm/addon-fit";
 import { WebLinksAddon } from "@xterm/addon-web-links";
+import { CanvasAddon } from "@xterm/addon-canvas";
 import type { UnlistenFn } from "@tauri-apps/api/event";
 import {
   readText as clipboardReadText,
@@ -149,6 +150,23 @@ export default function XtermPane({
     );
     term.open(container);
 
+    // Use the canvas renderer instead of xterm's default DOM renderer.
+    // The DOM renderer draws the cursor as a separate layered element and,
+    // under the Claude TUI's rapid hide/show (\x1b[?25l/h) + cursorBlink,
+    // leaves a stale cursor block frozen where the cursor used to be (the
+    // "stuck white marker"). The canvas renderer composites the cursor into
+    // the same surface as the text, so hide/show transitions clear cleanly.
+    // Chosen over the WebGL addon because tiletopia runs many panes at once
+    // and Chromium/WebView2 caps live WebGL contexts (~16) — canvas has no
+    // such hard limit. Loaded after open() so the core renderer exists.
+    try {
+      term.loadAddon(new CanvasAddon());
+    } catch (e) {
+      // If canvas init fails for any reason, xterm falls back to the DOM
+      // renderer on its own — degrade gracefully rather than blank the pane.
+      console.warn("CanvasAddon load failed; using DOM renderer:", e);
+    }
+
     // Initial size — fit before asking the PTY for its dimensions.
     fit.fit();