Can we reset CSI u mode on client disconnect? via

[David Leadbeater]

On Mon, 8 Jul 2024 at 11:58, Damien Miller <djm at mindrot.org> wrote:
> ssh already restores all TTY flags on exit:

This isn't a TTY flag, it's a terminal mode enabled via an escape
sequence, there's actually multiple modes involved (CSI u as in the
subject), but xterm also supports "modifyOtherKeys" and Vim for
example will pick depending what the terminal reports support for.

The closest thing which ssh could do would be the code equivalent of
"tput rs2", but OpenSSH isn't likely to link to ncurses just for that,
and it seems like for most terminals "rs1" is needed to reset the
terminal key handling state (but that clears the screen too, which
seems undesirable).

It's worth pointing out this also reproduces if you kill -9 vim
locally (on a recent Vim and a terminal which supports these key
handling modes), i.e. an unexpected exit from Vim can trigger it, so
SSH losing a connection where Vim can't run its exit handler is just a
manifestation of the problem. As mentioned in the Kitty issue, shells
should really gain support for input modes.

As a workaround it would be possible to put the key reset sequence in
the shell prompt or Zsh is actually programmable enough to handle
unexpected CSI key sequences and then turn them off. Example .zshrc
snippet:

function skip-csi-sequence() {
  local key
  while read -sk key && (( $((#key)) < 0x40 || $((#key)) > 0x7E )); do
    # empty body
  done
  if [[ $key = u ]] || [[ $key = "~" ]]; then
    # Ensure keys are sent normally, zle doesn't expect modifyOtherKeys / CSI u
    # (This means this key press is discarded, but the next one should
be handled.)
    printf '\e[>4m\e[<u'
  fi
}

zle -N skip-csi-sequence
bindkey '\e[' skip-csi-sequence

Based on that it would probably be possible to write a Zsh extension
that does handle CSI u properly, which would fix this for Zsh users at
least...

David