From f8fc81f4741714de6ff011874b520ba049a9bb1b Mon Sep 17 00:00:00 2001 From: Julien Calixte Date: Wed, 1 Jul 2026 20:00:19 +0200 Subject: [PATCH] docs(adr): record CLI engine over per-editor extension --- ...001-cli-engine-over-per-editor-extension.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 docs/adr/0001-cli-engine-over-per-editor-extension.md diff --git a/docs/adr/0001-cli-engine-over-per-editor-extension.md b/docs/adr/0001-cli-engine-over-per-editor-extension.md new file mode 100644 index 0000000..c5e5fbb --- /dev/null +++ b/docs/adr/0001-cli-engine-over-per-editor-extension.md @@ -0,0 +1,18 @@ +# CLI engine with per-editor keystroke shims, not a per-editor extension + +**Status:** accepted + +Dantotsu Print's capture layer is a single `dp` CLI engine, invoked by a thin per-editor keystroke shim (Vim map, JetBrains External Tool, VS Code/Cursor keybinding→task; Xcode falls back to clipboard). We chose this over a native extension per editor because the engineering fleet is polyglot (VS Code, Cursor, JetBrains, Vim, Xcode) and maintaining five extensions would multiply operating burden against F4 — while one engine plus thin shims stays editor-agnostic. + +## Considered options + +- **Per-editor extensions** (Polacode-style). Richest UX, free git context — but one codebase per editor to maintain. +- **CLI engine + keystroke shims (chosen).** One engine, thin shims; editor-agnostic; the CLI resolves git context itself. +- **Web paste-in.** Zero install, but reintroduces the Notion-like friction this project exists to remove. + +## Consequences + +- Weaker in-editor preview — mitigated by a cell-accurate terminal/OS preview (F3a), inline in graphics-capable terminals (Ghostty, iTerm2, …). +- Xcode is degraded to clipboard-only (no precise line range). +- Syntax colours come from the CLI's own tokenizer, not the editor's live theme. +- A VS Code/Cursor extension may be added later as a fast-follow for a richer preview — one codebase covers the largest slice of the fleet.