summaryrefslogtreecommitdiff
path: root/skills/google-style-guide/reference/technical.md
diff options
context:
space:
mode:
authorIgor Soarez <igor@soarez.org>2026-10-26 16:20:45 +0200
committerIgor Soarez <igor@soarez.org>2026-10-26 16:20:45 +0200
commit65d3da052dcecba82f05e4244f33c3f489b575c5 (patch)
treeac7fd673208f38d45d9aa9a4d8e3a0e815e7cde3 /skills/google-style-guide/reference/technical.md
parent4f40b8ea2f224132dddde4f505191c3662620741 (diff)
tmux: Shift+Enter reaches pi, Neovim and Claude Code under Ghostty
With extended-keys off, tmux hands every pane a plain CR for Shift+Enter and Ctrl+Enter, so pi submits where it should add a line, and warns about it at every start. Turning it on is not enough on its own, though pi's warning then goes quiet: tmux asks the outer terminal for modified keys only when it knows the terminal can send them, and tmux does not recognise Ghostty, whose terminfo does not declare it either. So Ghostty also gets the extkeys feature, and the format is csi-u, the one pi asks for. `on`, not `always`, which would send zsh ESC[13;2u for Shift+Enter. The paste corruption the old comment blamed on extended keys shows up only in a display-popup, where tmux re-encodes the newlines of a paste for an app that asked for modified keys; normal panes get the pasted bytes unchanged. Nothing here opens popups. Checked on tmux 3.7c against a pty answering as Ghostty 1.3.1, with pi itself in the pane, and by hand in Ghostty on a separate tmux server. The csi-u line is set with -q, since extended-keys-format arrived in tmux 3.5; 3.4 was not tried, only an unknown option name standing in for it.
Diffstat (limited to 'skills/google-style-guide/reference/technical.md')
0 files changed, 0 insertions, 0 deletions