fix: skip shell-integration wait for shells without SI support (fixes #1391)

[StellaHuang95]

Summary

Fixes #1391 — terminal activation is slow on nushell (and any other shell VS Code doesn't provide shell integration for).

When a Python terminal opens in command activation mode, waitForShellIntegration() is awaited before sending the activation command. For shells VS Code does not provide shell integration for — nu, cmd, csh, tcsh, ksh, xonsh — the onDidChangeTerminalShellIntegration event never fires, the prompt-pattern heuristic is unreliable, and the wait runs out the full 5 s default timeout (per getShellIntegrationTimeout() when terminal.integrated.shellIntegration.enabled is true). Once the wait completes, activation falls back to terminal.sendText anyway — so the delay is pure overhead and visibly disrupts the user's typing in the new terminal.

Root cause

waitForShellIntegration() in src/features/terminal/utils.ts doesn't consult the codebase's existing source of truth for SI-capable shells (shellIntegrationSupportedShells in src/features/terminal/shells/common/shellUtils.ts). For nu, that means it always times out.

Fix

After the existing terminal.shellIntegration early-return in waitForShellIntegration, identify the shell via identifyTerminalShell() and return false immediately when the shell type is known and not in shellIntegrationSupportedShells. Wrapped in try/catch so any detection failure (or 'unknown' result) falls through to the existing Promise.race body — strictly additive: best case faster, worst case identical to today.

This:

• Reuses the codebase's single source of truth (shellIntegrationSupportedShells), so adding a new SI-capable shell automatically benefits both this code and shouldUseProfileActivation.
• Returns the same value (false) the function would have eventually returned — semantics unchanged for all callers, only latency differs.
• Preserves all existing behavior for supported shells (pwsh, bash, gitbash, fish, zsh).
• Defensive try/catch and explicit 'unknown' check make the change non-regressing even if shell detection fails.

For nu users, this turns the ~5 s freeze before overlay use ...activate.nu runs into an imperceptible delay.

Testing

Manual

On main with nu configured as default profile and python-envs.terminal.autoActivationType: "command":

• Open new terminal → ~5 s gap between prompt appearing and activation command running.

On this branch, same setup:

• Open new terminal → activation command runs immediately after the prompt.
• Python Environments output channel logs: Shell 'nu' does not support shell integration; skipping wait.

Verified the fix does not alter behavior for pwsh / bash (they still wait for SI to come up, which they do quickly).

Automated

8 new unit tests in Terminal Utils - waitForShellIntegration cover:

• undefined terminal → false immediately
• terminal.shellIntegration already set → true immediately, no shell detection
• nu → false immediately, no event listeners registered
• cmd → false immediately
• csh / tcsh / ksh / xonsh → all false immediately
• bash → falls through to event race, resolves true when SI event fires
• unknown shell → falls through to race
• identifyTerminalShell throws → falls through to race (defensive)

npm run lint           # clean
npm run compile-tests  # clean
npm run unittest       # 992 passing (including the 8 new tests), 2 pending

Related

• [Python Environments] Virtual environment activation is slow #997 — original "Virtual environment activation is slow" tracking issue, where the maintainer explicitly noted: "In case shell does not support dynamic evals like nu, it will fall back to command activation." This PR makes that command-activation fallback fast.

Risk

Low. Fully covered by tests. The change is gated by try/catch and an explicit allow-list, so the worst case (detection fails or returns 'unknown') is identical to current behavior.

[StellaHuang95]

@anthonykim1 I made some changes around shell integration, would you mind taking a look as well? Thanks!

[anthonykim1]

@StellaHuang95 This looks good, thank you