diff options
| author | Igor Soarez <igor@soarez.org> | 2026-10-26 16:20:45 +0200 |
|---|---|---|
| committer | Igor Soarez <igor@soarez.org> | 2026-10-26 16:20:45 +0200 |
| commit | 65d3da052dcecba82f05e4244f33c3f489b575c5 (patch) | |
| tree | ac7fd673208f38d45d9aa9a4d8e3a0e815e7cde3 /Brewfile | |
| parent | 4f40b8ea2f224132dddde4f505191c3662620741 (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 'Brewfile')
0 files changed, 0 insertions, 0 deletions
