…icrosoft#1391) (microsoft#1501) ## Summary Fixes microsoft#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`](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`](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 - microsoft#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.

Uh oh!

Terminal activation is slow on nushell #1391

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions