Merge pull request 'Scroll copy mode 4 lines per mouse wheel tick instead of half a page' (#8) from tmux-wheel-scroll-4 into master

Reviewed-on: #8
Reviewed-by: branderson <brad@branderson.io>

config/nvim/lua/plugins/lsp.lua

@@ -1,4 +1,21 @@
-local servers = { "basedpyright", "ruff" }
+-- ruff is a prebuilt GitHub release binary, but mason installs basedpyright
+-- from PyPI into a venv. Debian ships venv's ensurepip separately
+-- (python3-venv), and without it every startup fails the install.
+local servers = { "ruff" }
+
+local function has_python_venv()
+  if vim.fn.executable("python3") ~= 1 then
+    return false
+  end
+  vim.fn.system({ "python3", "-c", "import ensurepip" })
+  return vim.v.shell_error == 0
+end
+
+if has_python_venv() then
+  table.insert(servers, "basedpyright")
+else
+  vim.notify("python3 venv unavailable (install python3-venv): skipping LSP server basedpyright", vim.log.levels.WARN)
+end
 
 local npm_servers = { "ts_ls", "svelte", "html", "cssls", "bashls" }
 local function has_public_npm()

config/tmux.conf

@@ -87,13 +87,26 @@ if-shell "tmux -V | awk '{print $2}' | awk -F. '{if ($1*1000+$2 >= 3003) exit 0;
 # itself using default-terminal above (screen-256color) -- 'xterm*' would
 # never match that, breaking the nested case this is meant to support.
 #
-# Investigated as a suspect for multi-line paste getting corrupted with
-# literal CSI 27;<mod>;<key>~ garbage in place of newlines (see Claude Code
-# issues #43169 and #30239) -- turning this off did not fix that paste
-# corruption, so it's an upstream Claude Code paste-tokenizer bug, not
-# something caused by this setting. Restored.
+# Not the cause of multi-line paste arriving with literal CSI 27;5;106~ in
+# place of each newline (that being C-j, the pasted newline, in
+# modifyOtherKeys form). That is a tmux 3.5/3.5a bug: 3.5 rewrote extended-key
+# handling and encodes keys inside a bracketed paste, which the layer further
+# in then passes through verbatim rather than decoding. Reproduced against
+# 3.2a/3.3a/3.4/3.5a/3.6b/3.7c -- only 3.5 and 3.5a corrupt, and only on a hop
+# whose downstream has asked for modifyOtherKeys mode 2, which a nested tmux
+# always does and a bare application under screen-256color generally doesn't.
+# Hence it shows up with tmux at both ends of the ssh and not with one.
+# Fixed upstream in 3.6, so upgrade the offending layer where that's possible.
 if-shell "tmux -V | awk '{print $2}' | awk -F. '{if ($1*1000+$2 >= 3002) exit 0; else exit 1}'" 'set -s extended-keys on; set -as terminal-features "*:extkeys"'
 
+# Where it isn't -- a host pinned to a distro tmux -- give the paste back on
+# just those two versions. Nothing narrower helps: csi-u format only changes
+# which escape lands in the text, and withholding the extkeys feature above
+# stops this tmux asking its own parent for extended keys without stopping it
+# encoding them for the pane. Turning them off is the whole of the workaround,
+# and confining it to 3.5/3.5a keeps them everywhere else.
+if-shell "tmux -V | awk '{hit = ($2 ~ /^3[.]5/)} END {exit hit ? 0 : 1}'" 'set -s extended-keys off'
+
 # Accept pane-originated OSC 52 clipboard-set attempts into a real tmux
 # buffer. Only on-vs-off matters here -- off would refuse to even look at
 # these escapes; "on" (rather than "external") is needed so the pane-set-

packages/apt.global

@@ -6,6 +6,9 @@ powerline
 thefuck
 tree
 nodejs
+# Debian splits venv's ensurepip out of python3; mason needs `python3 -m venv`
+# to install PyPI-sourced LSP servers (basedpyright)
+python3-venv
 zsh
 htop
 jq