jiebi/CodeConvo huggingface dataset:
Code change:
Connect a mac-windows SSH remote Open terminal See this popup ! So fails here because it checks ".PATH" on the environment when this is actually "Path" on windows. has special behavior where it resolves property accesses in a case-insensitive way on Windows. We changed many accesses from using to a constructed environment object, and need the same behavior there.
is this a mac-specific issue or are there steps to repro/verify on Windows?
Can't be verified on windows. Thanks

Related discussion:
text: const fullPath = path.join(cwd, command); return await exists(fullPath) ? fullPath : undefined; } <del> if (paths === undefined && isString(env.PATH)) { paths = env.PATH.split(path.delimiter); </del> <ins> const envPath = getCaseInsensitive(env, 'PATH'); if (paths === undefined && isString(envPath)) { paths = envPath.split(path.delimiter); </ins> } // No PATH environment. Make path absolute to the cwd. if (paths === undefined || paths.length === 0) {
Code change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.50.1 OS Version: Steps to Reproduce: vscode/extensions/theme-tomorrow-night- that wrong value for themeLabel is given ("Quiet Light" instead of "Tomorrow Night Blue") <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes Incorrect value "Quiet Light" commited in

Related discussion:
text: { "displayName": "Tomorrow Night Blue Theme", "description": "Tomorrow night blue theme for Visual Studio Code", <del> "themeLabel": "Quiet Light" </del> <ins> "themeLabel": "Tomorrow Night Blue" </ins> }
Code change:
Testing Unfiltered notebook noob feedback: ! I was expecting a tooltip to tell me what it meant.
Agreed that we should add tooltip for it.
how would you interpret it if there was a tooltip that said "Execution Order"?
when you run all cells it goes in that order? I was expecting that to be sequential from the top?
It's the order that it was executed it, not the order it will execute in. Hopefully a user would figure that out if they run the cell and see it change.
oh, more explicit would be better then imo I also question why this is useful but I'm guessing this is a common notebooks feature elsewhere?
Yeah it's what people expect from Jupyter and can help you understand the state of the kernel
Thanks that needs to be localized though. btw if you are going to merge your change in, you can just commit directly, no PR needed

Related discussion:
text: const runToolbar = this.setupRunToolbar(runButtonContainer, container, contextKeyService, disposables); const executionOrderLabel = DOM.append(cellContainer, $('div.execution-count-label')); <ins> executionOrderLabel.setAttribute('title', 'Execution Order'); </ins> const editorPart = DOM.append(cellContainer, $('.cell-editor-part')); const editorContainer = DOM.append(editorPart, $('.cell-editor-container'));
Code change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --FYI Related to ? Steps to Reproduce: Set up a keybinding for with any Trigger the keybinding, search editor opens but none of the are used Same keybinding works in Stable Demo using a workspace file: Same result: (not involving OneDrive) ! <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes Version: 1.53.0-insider (user setup) Commit: Date: 2021-01-29T21:49:22.151Z Electron: 11.2.1 Chrome: 87.0.4280.141 12.18.3 V8: 8.7.220.31-electron.0 OS: Windows_NT x64 10.0. Log Window) with enabled: [2021-01-31 19:44:09.185] [renderer1] [trace] CommandService#executeCommand [2021-01-31 19:44:15.502] [renderer1] [trace] KeybindingService#dispatch Ctrl+Shift+G [2021-01-31 19:44:15.502] [renderer1] [trace] CommandService#executeCommand
Thanks, I can reproduce.
To verify: Add a keybinding like: Execute it, expect to see the context line input properly filled out.
Works for me (W10). Used this keybinding just to test more args (see below for a comment in the args): I suppose an issue should be filed on not working if it was intended to - it does properly insert the full path, ala but fails silently and button does nothing.
thanks, as far as I'm aware directly putting that absolute path into the entry would fail as well, correct? So not a new issue.
Yes, it fails inserting it directly into the arg (escaped properly) and in the view in the Panel input - although in Search view it does show the error highlight around the query box and hover error message. I will not file an issue on this.

Related discussion:
text: registerAction2(class OpenSearchEditorAction extends Action2 { constructor() { super({ <del> id: SearchEditorConstants.OpenNewEditorCommandId, title: localize('search.openNewEditor', "Open New Search Editor"), </del> <ins> id: 'search.action.openNewEditorFromView', title: localize('search.openNewEditor', "Open New Search Editor from View"), </ins> category, icon: searchNewEditorIcon, <del> f1: true, </del> menu: [{ id: MenuId.ViewTitle, group: 'navigation',
Code change:
There is no drop hover feedback in the Explorer, for example, when in Light+ theme.
Broken by:

Related discussion:
text: export const listInactiveFocusOutline = registerColor('list.inactiveFocusOutline', { dark: null, light: null, hc: null }, nls.localize('listInactiveFocusOutline', "List/Tree outline color for the focused item when the list/tree is inactive. An active list/tree has keyboard focus, an inactive does not.")); export const listHoverBackground = registerColor('list.hoverBackground', { dark: '#2A2D2E', light: '#F0F0F0', hc: null }, nls.localize('listHoverBackground', "List/Tree background when hovering over items using the mouse.")); export const listHoverForeground = registerColor('list.hoverForeground', { dark: null, light: null, hc: null }, nls.localize('listHoverForeground', "List/Tree foreground when hovering over items using the mouse.")); <del> export const listDropBackground = registerColor('list.dropBackground', { dark: listFocusBackground, light: listFocusBackground, hc: null }, nls.localize('listDropBackground', "List/Tree drag and drop background when moving items around using the mouse.")); </del> <ins> export const listDropBackground = registerColor('list.dropBackground', { dark: '#062F4A', light: '#D6EBFF', hc: null }, nls.localize('listDropBackground', "List/Tree drag and drop background when moving items around using the mouse.")); </ins> export const listHighlightForeground = registerColor('list.highlightForeground', { dark: '#0097fb', light: '#0066BF', hc: focusBorder }, nls.localize('highlight', 'List/Tree foreground color of the match highlights when searching inside the list/tree.')); export const listInvalidItemForeground = registerColor('list.invalidItemForeground', { dark: '#B89500', light: '#B89500', hc: '#B89500' }, nls.localize('invalidItemForeground', 'List/Tree foreground color for invalid items, for example an unresolved root in explorer.')); export const listErrorForeground = registerColor('list.errorForeground', { dark: '#F88070', light: '#B01011', hc: null }, nls.localize('listErrorForeground', 'Foreground color of list items containing errors.'));
Code change:
We should filter out the terminal if this is undefined, otherwise bad bugs like could happen where we restore a terminal into the wrong window: The chances of this happening are pretty slim so not doing this in Feb.
Falling back to 0 as it has been seems to work well, if we need to handle this on reconnect we will have a persistentProcessId of 0 which isn't valid anyway.

Related discussion:
text: private _startBarrier: Barrier; private _persistentTerminalId: number; <ins> public get id(): number { return this._persistentTerminalId; } </ins> private _inReplay = false; constructor( <del> readonly id: number, </del> <ins> private readonly _instanceId: number, </ins> readonly shouldPersist: boolean, private readonly _shellLaunchConfig: IShellLaunchConfig, private readonly _activeWorkspaceRootUri: URI | undefined,
Code change:
We should filter out the terminal if this is undefined, otherwise bad bugs like could happen where we restore a terminal into the wrong window: The chances of this happening are pretty slim so not doing this in Feb.
Falling back to 0 as it has been seems to work well, if we need to handle this on reconnect we will have a persistentProcessId of 0 which isn't valid anyway.

Related discussion:
text: env: this._shellLaunchConfig.env }; <del> this._logService.trace('Spawning remote agent process', { terminalId: this.id, shellLaunchConfigDto }); </del> <ins> this._logService.trace('Spawning remote agent process', { terminalId: this._instanceId, shellLaunchConfigDto }); </ins> const result = await this._remoteTerminalChannel.createTerminalProcess( shellLaunchConfigDto,
Code change:
We should filter out the terminal if this is undefined, otherwise bad bugs like could happen where we restore a terminal into the wrong window: The chances of this happening are pretty slim so not doing this in Feb.
Falling back to 0 as it has been seems to work well, if we need to handle this on reconnect we will have a persistentProcessId of 0 which isn't valid anyway.

Related discussion:
text: this.onActiveTabChanged(() => isRemote ? this._updateRemoteState() : this._updateLocalState()); this.onActiveInstanceChanged(() => isRemote ? this._updateRemoteState() : this._updateLocalState()); this.onInstancesChanged(() => isRemote ? this._updateRemoteState() : this._updateLocalState()); <ins> // The state must be updated when the terminal is relaunched, otherwise the persistent // terminal ID will be stale and the process will be leaked. this.onInstanceProcessIdReady(() => isRemote ? this._updateRemoteState() : this._updateLocalState()); </ins> } public setNativeWindowsDelegate(delegate: ITerminalNativeWindowsDelegate): void {
Code change:
We should filter out the terminal if this is undefined, otherwise bad bugs like could happen where we restore a terminal into the wrong window: The chances of this happening are pretty slim so not doing this in Feb.
Falling back to 0 as it has been seems to work well, if we need to handle this on reconnect we will have a persistentProcessId of 0 which isn't valid anyway.

Related discussion:
text: terminals: instances.map(t => { return { relativeSize: isHorizontal ? t.cols / totalSize : t.rows / totalSize, <del> terminal: t.persistentTerminalId ? t.persistentTerminalId : t.id </del> <ins> terminal: t.persistentTerminalId || 0 </ins> }; }) };
Code change:
Tracks bundling TS 4.2.3 with VS Code. This includes a
Should be in recovery and in main now

Related discussion:
text: "license": "MIT", "description": "Dependencies shared by all extensions", "dependencies": { <del> "typescript": "4.2.2" </del> <ins> "typescript": "4.2.3" </ins> }, "scripts": { "postinstall": "node ./postinstall"
Code change:
Tracks bundling TS 4.2.3 with VS Code. This includes a
Should be in recovery and in main now

Related discussion:
text: resolved "https://registry.yarnpkg.com/fast-plist/-/fast-plist-0.1.2.tgz#a45aff345196006d406ca6cdcd05f69051ef35b8" integrity sha1-pFr/NFGWAG1AbKbNzQX2kFHvNbg= <del> typescript@4.2.2: version "4.2.2" resolved "https://registry.yarnpkg.com/typescript/-/typescript-4.2.2.tgz#1450f020618f872db0ea17317d16d8da8ddb8c4c" integrity sha512-tbb+NVrLfnsJy3M59lsDgrzWIflR4d4TIUjz+heUnHZwdF7YsrMTKoRERiIvI2lvBG95dfpLxB21WZhys1bgaQ== </del> <ins> typescript@4.2.3: version "4.2.3" resolved "https://registry.yarnpkg.com/typescript/-/typescript-4.2.3.tgz#39062d8019912d43726298f09493d598048c1ce3" integrity sha512-qOcYwxaByStAWrBf4x0fibwZvMRG+r4cQoTjbPtUlrWjBHbmCAww1i448U0GJ+3cNNEtebDteo/cHOR3xJ4wEw== </ins> vscode-grammar-updater@^1.0.3: version "1.0.3"
Code change:
Depends on This is common for process explorers on Windows at least, might also make sense to bring this to Linux.
This should be doable now that has landed via

Related discussion:
text: import { NativeHostService } from 'vs/platform/native/electron-sandbox/nativeHostService'; import { getIconsStyleSheet } from 'vs/platform/theme/browser/iconsStyleSheet'; import { applyZoom, zoomIn, zoomOut } from 'vs/platform/window/electron-sandbox/window'; <ins> import { StandardKeyboardEvent } from 'vs/base/browser/keyboardEvent'; import { KeyCode } from 'vs/base/common/keyCodes'; </ins> const DEBUG_FLAGS_PATTERN = /s--(inspect|debug)(-brk|port)?=(d+)?/; const DEBUG_PORT_PATTERN = /s--(inspect|debug)-port=(d+)/;
Code change:
Depends on This is common for process explorers on Windows at least, might also make sense to bring this to Linux.
This should be doable now that has landed via

Related discussion:
text: this.tree.setInput({ processes: { processRoots } }); this.tree.layout(window.innerHeight, window.innerWidth); <ins> this.tree.onKeyDown(e => { const event = new StandardKeyboardEvent(e); if (event.keyCode === KeyCode.KeyE && event.altKey) { const selectionPids = this.getSelectedPids(); void Promise.all(selectionPids.map((pid) => this.nativeHostService.killProcess(pid, 'SIGTERM'))).then(() => this.tree?.refresh()); } }); </ins> this.tree.onContextMenu(e => { if (isProcessItem(e.element)) { this.showContextMenu(e.element, true);
Code change:
Depends on This is common for process explorers on Windows at least, might also make sense to bring this to Linux.
This should be doable now that has landed via

Related discussion:
text: label: localize('copy', "Copy"), click: () => { // Collect the selected pids <del> const selectionPids = this.tree?.getSelection()?.map(e => { if (!e || !('pid' in e)) { return undefined; } return e.pid; }).filter(e => !!e) as number[]; </del> <ins> const selectionPids = this.getSelectedPids(); </ins> // If the selection does not contain the right clicked item, copy the right clicked // item only. if (!selectionPids?.includes(pid)) {
Code change:
Depends on This is common for process explorers on Windows at least, might also make sense to bring this to Linux.
This should be doable now that has landed via

Related discussion:
text: } }, 200); } <ins> private getSelectedPids() { return this.tree?.getSelection()?.map(e => { if (!e || !('pid' in e)) { return undefined; } return e.pid; }).filter(e => !!e) as number[]; } </ins> } function createCodiconStyleSheet() {
Code change:
It doesn't look right compared to all the other placeholders: ! It's more noticeable when using editor font (font gets smaller): VS Code version: Code - Insiders 1.56.0-insider (, 2021-04-16T11:25:09.662Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --

Related discussion:
text: position: absolute; pointer-events: none; z-index: 1; <del> padding: 2px 6px 3px 6px; </del> <ins> padding: 3px 6px; </ins> box-sizing: border-box; width: 100%; overflow: hidden;
Code change:
See I think the best way for this would be for VS Code core to rename the terminal if gets a new request with a different name -- opened an issue for that Or, at least, try to use a terminal of the same name if one exists (which would be easier and probably more feasible since the is not writable.) Code pointer:
Also fyi
I'm going to take a swing at this. Here is my current understanding of the problem and I would appreciate any feedback or comments. The issue - Launching debug sessions in integrated terminal will open duplicate terminals. Solution - Code can attempt to find a terminal instance that has the same title as the launch request and is not currently in use. If located, it can reuse that instance, otherwise it can use the existing logic to create a new instance. I believe this should also address the concerns in as Code will stop spawning new terminal instances for repeat debug sessions. Please let me know if I have any misunderstandings on the issue.
Sounds good to me
I'm looking over the current code for checking out an integrated terminal and came across the minUseDelay for determining which of the terminals is available for use. It was a fix for . As I understand it, when compound node tasks were run, they would all try to grab the same terminal instance so only the first one to run would actually get the terminal, the others would fail to run. By introducing the minUseDelay, it insured that all of the launch tasks would get a new terminal instance. Once microsoft/vscode-js-debug is merged, each Node launch task will most likely have a unique name and therefore a dedicated terminal instance (ideally) which would mean we could always return the first terminal without a child process that has the same title and get rid of minUseDelay. Right?
Obviously if someone had two launch configurations with the same name (why?) this would fall apart.
We could even enforce name-matching and reopen the terminal if nothing's running in it and the name mismatches

Related discussion:
text: const shell = this._terminalService.getDefaultShell(true, configProvider); const shellArgs = this._terminalService.getDefaultShellArgs(true, configProvider); <ins> const terminalName = args.title || nls.localize('debug.terminal.title', "Debug Process"); </ins> const shellConfig = JSON.stringify({ shell, shellArgs }); <del> let terminal = await this._integratedTerminalInstances.checkout(shellConfig); </del> <ins> let terminal = await this._integratedTerminalInstances.checkout(shellConfig, terminalName); </ins> let cwdForPrepareCommand: string | undefined; let giveShellTimeToInitialize = false;
Code change:
See I think the best way for this would be for VS Code core to rename the terminal if gets a new request with a different name -- opened an issue for that Or, at least, try to use a terminal of the same name if one exists (which would be easier and probably more feasible since the is not writable.) Code pointer:
Also fyi
I'm going to take a swing at this. Here is my current understanding of the problem and I would appreciate any feedback or comments. The issue - Launching debug sessions in integrated terminal will open duplicate terminals. Solution - Code can attempt to find a terminal instance that has the same title as the launch request and is not currently in use. If located, it can reuse that instance, otherwise it can use the existing logic to create a new instance. I believe this should also address the concerns in as Code will stop spawning new terminal instances for repeat debug sessions. Please let me know if I have any misunderstandings on the issue.
Sounds good to me
I'm looking over the current code for checking out an integrated terminal and came across the minUseDelay for determining which of the terminals is available for use. It was a fix for . As I understand it, when compound node tasks were run, they would all try to grab the same terminal instance so only the first one to run would actually get the terminal, the others would fail to run. By introducing the minUseDelay, it insured that all of the launch tasks would get a new terminal instance. Once microsoft/vscode-js-debug is merged, each Node launch task will most likely have a unique name and therefore a dedicated terminal instance (ideally) which would mean we could always return the first terminal without a child process that has the same title and get rid of minUseDelay. Right?
Obviously if someone had two launch configurations with the same name (why?) this would fall apart.
We could even enforce name-matching and reopen the terminal if nothing's running in it and the name mismatches

Related discussion:
text: shellPath: shell, shellArgs: shellArgs, cwd: args.cwd, <del> name: args.title || nls.localize('debug.terminal.title', "debuggee"), </del> <ins> name: terminalName, </ins> }; giveShellTimeToInitialize = true; terminal = this._terminalService.createTerminalFromOptions(options, true);
Code change:
See I think the best way for this would be for VS Code core to rename the terminal if gets a new request with a different name -- opened an issue for that Or, at least, try to use a terminal of the same name if one exists (which would be easier and probably more feasible since the is not writable.) Code pointer:
Also fyi
I'm going to take a swing at this. Here is my current understanding of the problem and I would appreciate any feedback or comments. The issue - Launching debug sessions in integrated terminal will open duplicate terminals. Solution - Code can attempt to find a terminal instance that has the same title as the launch request and is not currently in use. If located, it can reuse that instance, otherwise it can use the existing logic to create a new instance. I believe this should also address the concerns in as Code will stop spawning new terminal instances for repeat debug sessions. Please let me know if I have any misunderstandings on the issue.
Sounds good to me
I'm looking over the current code for checking out an integrated terminal and came across the minUseDelay for determining which of the terminals is available for use. It was a fix for . As I understand it, when compound node tasks were run, they would all try to grab the same terminal instance so only the first one to run would actually get the terminal, the others would fail to run. By introducing the minUseDelay, it insured that all of the launch tasks would get a new terminal instance. Once microsoft/vscode-js-debug is merged, each Node launch task will most likely have a unique name and therefore a dedicated terminal instance (ideally) which would mean we could always return the first terminal without a child process that has the same title and get rid of minUseDelay. Right?
Obviously if someone had two launch configurations with the same name (why?) this would fall apart.
We could even enforce name-matching and reopen the terminal if nothing's running in it and the name mismatches

Related discussion:
text: private _terminalInstances = new Map<vscode.Terminal, { lastUsedAt: number, config: string }>(); <del> public async checkout(config: string) { </del> <ins> public async checkout(config: string, name: string) { </ins> const entries = [...this._terminalInstances.entries()]; const promises = entries.map(([terminal, termInfo]) => createCancelablePromise(async ct => { <ins> // Only allow terminals that match the title.  See #123189 if (terminal.name !== name) { return null; } </ins> if (termInfo.lastUsedAt !== -1 && await hasChildProcesses(await terminal.processId)) { return null; }
Code change:
Steps to Reproduce: Workspace and trust it code-insiders from a folder that is not trusted. -Shows the dialog code-insiders from a folder that is not trusted. -No warning dialog the window code-insiders from a folder that is not trusted. Expected: No warning dialog should be shown Actual: A warning dialog is being shown
Pushed a fix for this to main. Fix is low risk so we can take it as a candidate.

Related discussion:
text: // Update workspace trust this._trustState.isTrusted = trusted; <ins> // Reset acceptsOutOfWorkspaceFiles if (!trusted) { this._trustState.acceptsOutOfWorkspaceFiles = false; } </ins> // Run workspace trust transition participants await this._trustTransitionManager.participate(trusted);
Code change:
Steps to Reproduce: Workspace and trust it code-insiders from a folder that is not trusted. -Shows the dialog code-insiders from a folder that is not trusted. -No warning dialog the window code-insiders from a folder that is not trusted. Expected: No warning dialog should be shown Actual: A warning dialog is being shown
Pushed a fix for this to main. Fix is low risk so we can take it as a candidate.

Related discussion:
text: set isTrusted(value: boolean | undefined) { this._mementoObject[this._isTrustedKey] = value; <del> if (!value) { this._mementoObject[this._acceptsOutOfWorkspaceFilesKey] = value; } </del> this._memento.saveMemento(); } }