What's wrong with this entry?
Anonymous. No account, no email.
The tmux option queries (mouse mode and focus-events state) are now performed once and cached per session. Previously each check that needed the tmux mouse or focus-events status spawned a new tmux show subprocess. The cached results are shared across all callers within the session.
Details
- Two queries are cached:
tmux show -Av mouse(detects mouse support) andtmux show -gv focus-events(detects focus-event state); each subprocess runs with a 2-second timeout - Cache keys
tmuxMouseOptionProbeandtmuxFocusOptionProbelive on the session-scoped probe-state object; each is initialized toundefinedand populated lazily on first access via a stored Promise using??=assignment, so concurrent callers share the same in-flight subprocess - Both probes are eagerly pre-warmed at startup via an early call when
$TMUXis set and iTerm.app control-mode is not active, so the results are already resolved by the time hint-display checks run - Mouse hint fires when the probe returns anything other than
"on": "tmux detected · scroll with PgUp/PgDn · or add 'set -g mouse on' to ~/.tmux.conf for wheel scroll"; only shown once per session via acheckedTmuxMouseHintboolean flag - Focus-events hint fires when the probe returns anything other than
"on": "tmux focus-events off · add 'set -g focus-events on' to ~/.tmux.conf and reattach for focus tracking"; similarly gated bycheckedTmuxFocusHint - A
nullresult from either probe (tmux binary not found, spawn failure, or non-zero exit code) suppresses that hint silently
Evidence
Tmux probe cache (search for "tmuxMouseOptionProbe" and "tmuxFocusOptionProbe")
Strings lifted out of the shipped bundle, so the claim above can be checked against them.