keychord_hint.go RawHistoryFolder

1package modes
2
3import (
4	"os"
5	"strings"
6)
7
8// slideBackChordHint returns the keyboard chord the user must press
9// to peel the most recently queued ("sliding in") message back into
10// the editor. The chord itself is decoded the same way everywhere
11// (see KeyUp with k.Alt in handleKey) — what changes is which
12// physical combo actually delivers a modified-arrow escape sequence
13// to the process:
14//
15//   - Ghostty, iTerm2 (with the "Esc+" / Meta=Option setting),
16//     Terminal.app (with "Use Option as Meta key"), Alacritty,
17//     Kitty: bare Option+Up sends \x1b[1;3A (mod=3 / Alt) which
18//     our parser reads as KeyUp + Alt. Good.
19//
20//   - VS Code's integrated terminal (xterm.js) on macOS does NOT
21//     forward Option+Up as an Alt-modified arrow by default — it
22//     either swallows the Option as a compose modifier or emits a
23//     character. But Option+Shift+Up reliably sends \x1b[1;4A
24//     (mod=4 / Shift+Alt) because the Shift bit forces the
25//     CSI-with-modifier path. Our parser already treats mod=4 as
26//     alt=true, so the binding fires; we just need to tell the
27//     user the right chord.
28//
29//   - Vev reserves Alt+Up for pane navigation. Alt+Shift+Up is
30//     forwarded to the child process as \x1b[1;4A instead.
31//
32// Detection is by $TERM_PROGRAM; VS Code sets this to "vscode" on
33// every platform it ships an integrated terminal on. The decoder
34// accepts both chords on any terminal, so getting the env-var sniff
35// wrong only ever shows a slightly-off hint string — never breaks
36// the binding itself.
37func slideBackChordHint() string {
38	if strings.EqualFold(os.Getenv("TERM_PROGRAM"), "vev") {
39		return "Alt+Shift+↑"
40	}
41	if strings.EqualFold(os.Getenv("TERM_PROGRAM"), "vscode") {
42		return "Option+Shift+↑"
43	}
44	return "Option+↑"
45}