jiebi/CodeConvo huggingface dataset:
Code change:
Lately (since a few days) I see the explorer show an expand all icon even though some folders are expanded (in a multi root workspace): <img width="300" alt="image" src="https://user-"This must be a recent regression, not sure if in explorer or tree widget.
See
This breaks my muscle memory, I always collapse the explorer to start a new task and the new behaviour breaks this. I really see no value of this new behaviour? It is not even expanding all folders, only the ones that can be resolved? What is the use case?
As a suggestion: only show the expand button when really all nodes are collapsed, but keep the collapse button when any node is expanded.
I'm with this is quite different behavior in a multi-root workspace, I have one workspace with 5 root folders and another with 10+, prior to this change clicking the expand/collapse button in explorer would collapse all the folders in each root folder, clicking again would then collapse all the root folders. What I get now is the following: If all root folders are collapsed, clicking the expand/collapse button does nothing If one root folder is open the expand/collapse button expands and collapses folders within that root folder More than one root folder open the same as before for all of the open root folders Perhaps we could have an option to opt-in to this new behavior, I can't think of a single reason why I would want to expand every folder in a project.
Feature got removed.

Related discussion:
text: listDropBackground?: Color; } <del> // Accepts a single or multiple workspace folders function hasExpandedRootChild(tree: WorkbenchCompressibleAsyncDataTree<ExplorerItem | ExplorerItem[], ExplorerItem, FuzzyScore>, treeInput: ExplorerItem | ExplorerItem[]): boolean { const inputsToCheck = []; if (Array.isArray(treeInput)) { inputsToCheck.push(...treeInput.filter(folder => tree.hasNode(folder) && !tree.isCollapsed(folder))); } else { inputsToCheck.push(treeInput); } for (const folder of inputsToCheck) { for (const [, child] of folder.children.entries()) { if (tree.hasNode(child) && tree.isCollapsible(child) && !tree.isCollapsed(child)) { return true; </del> <ins> function hasExpandedRootChild(tree: WorkbenchCompressibleAsyncDataTree<ExplorerItem | ExplorerItem[], ExplorerItem, FuzzyScore>, treeInput: ExplorerItem[]): boolean { for (const folder of treeInput) { if (tree.hasNode(folder) && !tree.isCollapsed(folder)) { for (const [, child] of folder.children.entries()) { if (tree.hasNode(child) && tree.isCollapsible(child) && !tree.isCollapsed(child)) { return true; } </ins> } } } <ins> return false; } /** * Whether or not any of the nodes in the tree are expanded */ function hasExpandedNode(tree: WorkbenchCompressibleAsyncDataTree<ExplorerItem | ExplorerItem[], ExplorerItem, FuzzyScore>, treeInput: ExplorerItem[]): boolean { for (const folder of treeInput) { if (tree.hasNode(folder) && !tree.isCollapsed(folder)) { return true; } } </ins> return false; }
Code change:
Lately (since a few days) I see the explorer show an expand all icon even though some folders are expanded (in a multi root workspace): <img width="300" alt="image" src="https://user-"This must be a recent regression, not sure if in explorer or tree widget.
See
This breaks my muscle memory, I always collapse the explorer to start a new task and the new behaviour breaks this. I really see no value of this new behaviour? It is not even expanding all folders, only the ones that can be resolved? What is the use case?
As a suggestion: only show the expand button when really all nodes are collapsed, but keep the collapse button when any node is expanded.
I'm with this is quite different behavior in a multi-root workspace, I have one workspace with 5 root folders and another with 10+, prior to this change clicking the expand/collapse button in explorer would collapse all the folders in each root folder, clicking again would then collapse all the root folders. What I get now is the following: If all root folders are collapsed, clicking the expand/collapse button does nothing If one root folder is open the expand/collapse button expands and collapses folders within that root folder More than one root folder open the same as before for all of the open root folders Perhaps we could have an option to opt-in to this new behavior, I can't think of a single reason why I would want to expand every folder in a project.
Feature got removed.

Related discussion:
text: this.tree.domFocus(); } <del> const treeInput = this.tree.getInput(); if (Array.isArray(treeInput)) { treeInput.forEach(folder => { folder.children.forEach(child => this.tree.hasNode(child) && this.tree.expand(child, true)); }); return; } </del> this.tree.expandAll(); }
Code change:
Lately (since a few days) I see the explorer show an expand all icon even though some folders are expanded (in a multi root workspace): <img width="300" alt="image" src="https://user-"This must be a recent regression, not sure if in explorer or tree widget.
See
This breaks my muscle memory, I always collapse the explorer to start a new task and the new behaviour breaks this. I really see no value of this new behaviour? It is not even expanding all folders, only the ones that can be resolved? What is the use case?
As a suggestion: only show the expand button when really all nodes are collapsed, but keep the collapse button when any node is expanded.
I'm with this is quite different behavior in a multi-root workspace, I have one workspace with 5 root folders and another with 10+, prior to this change clicking the expand/collapse button in explorer would collapse all the folders in each root folder, clicking again would then collapse all the root folders. What I get now is the following: If all root folders are collapsed, clicking the expand/collapse button does nothing If one root folder is open the expand/collapse button expands and collapses folders within that root folder More than one root folder open the same as before for all of the open root folders Perhaps we could have an option to opt-in to this new behavior, I can't think of a single reason why I would want to expand every folder in a project.
Feature got removed.

Related discussion:
text: if (treeInput === undefined) { return; } <del> this.viewHasSomeCollapsibleRootItem.set(hasExpandedRootChild(this.tree, treeInput)); </del> <ins> const treeInputArray = Array.isArray(treeInput) ? treeInput : Array.from(treeInput.children.values()); // Has collapsible root when anything is expanded this.viewHasSomeCollapsibleRootItem.set(hasExpandedNode(this.tree, treeInputArray)); </ins> } styleListDropBackground(styles: IExplorerViewStyles): void {
Code change:
Steps: some changes on the "continue working on..." command and open in desktop :bug: VS Code opens but nothing loads https://user- Desktop Version: 1.70.0-insider (Universal) Commit: Date: 2022-07-26T05:17:37.262Z Electron: 18.3.5 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Darwin arm64 21.6.0 Web Version: 1.70.0-insider Commit: Date: 2022-07-26T05:17:04.193Z Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36
This action should be disabled in since we cannot access the local filesystem from the browser.
I'm still able to run the command from insiders vscode dev in Firefox. My Desktop Insiders then opens the repo using remote repositories but on the main branch instead of the branch I was working on. I'm not sure if this is the expected behaviour
I verified that this now works as expected https://user-

Related discussion:
text: import { EditSessionsDataViews } from 'vs/workbench/contrib/editSessions/browser/editSessionsViews'; import { ITextModelService } from 'vs/editor/common/services/resolverService'; import { EditSessionsContentProvider } from 'vs/workbench/contrib/editSessions/browser/editSessionsContentProvider'; <ins> import { isNative } from 'vs/base/common/platform'; import { WorkspaceFolderCountContext } from 'vs/workbench/common/contextkeys'; </ins> registerSingleton(IEditSessionsLogService, EditSessionsLogService); registerSingleton(IEditSessionsWorkbenchService, EditSessionsWorkbenchService);
Code change:
Steps: some changes on the "continue working on..." command and open in desktop :bug: VS Code opens but nothing loads https://user- Desktop Version: 1.70.0-insider (Universal) Commit: Date: 2022-07-26T05:17:37.262Z Electron: 18.3.5 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Darwin arm64 21.6.0 Web Version: 1.70.0-insider Commit: Date: 2022-07-26T05:17:04.193Z Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36
This action should be disabled in since we cannot access the local filesystem from the browser.
I'm still able to run the command from insiders vscode dev in Firefox. My Desktop Insiders then opens the repo using remote repositories but on the main branch instead of the branch I was working on. I'm not sure if this is the expected behaviour
I verified that this now works as expected https://user-

Related discussion:
text: id: '_workbench.experimental.editSessions.actions.continueEditSession', title: { value: localize('continue edit session', "Continue Edit Session..."), original: 'Continue Edit Session...' }, category: EDIT_SESSION_SYNC_CATEGORY, <ins> precondition: WorkspaceFolderCountContext.notEqualsTo('0'), </ins> f1: true }; const openLocalFolderCommand: IAction2Options = {
Code change:
Steps: some changes on the "continue working on..." command and open in desktop :bug: VS Code opens but nothing loads https://user- Desktop Version: 1.70.0-insider (Universal) Commit: Date: 2022-07-26T05:17:37.262Z Electron: 18.3.5 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Darwin arm64 21.6.0 Web Version: 1.70.0-insider Commit: Date: 2022-07-26T05:17:04.193Z Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36
This action should be disabled in since we cannot access the local filesystem from the browser.
I'm still able to run the command from insiders vscode dev in Firefox. My Desktop Insiders then opens the repo using remote repositories but on the main branch instead of the branch I was working on. I'm not sure if this is the expected behaviour
I verified that this now works as expected https://user-

Related discussion:
text: private createPickItems(): ContinueEditSessionItem[] { const items = [...this.continueEditSessionOptions].filter((option) => option.when === undefined || this.contextKeyService.contextMatchesRules(option.when)); <del> if (getVirtualWorkspaceLocation(this.contextService.getWorkspace()) !== undefined) { </del> <ins> if (getVirtualWorkspaceLocation(this.contextService.getWorkspace()) !== undefined && isNative) { </ins> items.push(new ContinueEditSessionItem( localize('continueEditSessionItem.openInLocalFolder', 'Open In Local Folder'), openLocalFolderCommand.id,
Code change:
Steps: some changes on the "continue working on..." command and open in desktop :bug: VS Code opens but nothing loads https://user- Desktop Version: 1.70.0-insider (Universal) Commit: Date: 2022-07-26T05:17:37.262Z Electron: 18.3.5 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Darwin arm64 21.6.0 Web Version: 1.70.0-insider Commit: Date: 2022-07-26T05:17:04.193Z Browser: Mozilla/5.0 (Macintosh; Intel Mac OS X ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36
This action should be disabled in since we cannot access the local filesystem from the browser.
I'm still able to run the command from insiders vscode dev in Firefox. My Desktop Insiders then opens the repo using remote repositories but on the main branch instead of the branch I was working on. I'm not sure if this is the expected behaviour
I verified that this now works as expected https://user-

Related discussion:
text: constructor() { super({ id: 'workbench.editSessions.actions.resetAuth', <del> title: localize('reset auth', 'Sign Out'), </del> <ins> title: localize('reset auth.v2', 'Sign Out of Edit Sessions'), </ins> category: EDIT_SESSION_SYNC_CATEGORY, precondition: ContextKeyExpr.equals(EDIT_SESSIONS_SIGNED_IN_KEY, true), menu: [{
Code change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.69.2 OS Version: MacOS BigSur and Monterey Steps to Reproduce: Open a terminal editor. a file from Finder into the terminal. This tries to open the file (unlike when the terminal is in the panel, which will paste the path).
I found that if I prevent the following code from executing, it works. So it seems like prevents the following code to handle pasting the file path. I did find that if you hold Shift before starting to drag the file, it will paste due to this code: I'm guessing there's some way to get that to realize it's a terminal editor and return as well.
I submitted PR for this.
File is still opened
did you hold shift? That's the method of passing the file through to the editor
works correctly with shift held

Related discussion:
text: } override get capabilities(): EditorInputCapabilities { <del> return EditorInputCapabilities.Readonly | EditorInputCapabilities.Singleton; </del> <ins> return EditorInputCapabilities.Readonly | EditorInputCapabilities.Singleton | EditorInputCapabilities.CanDropIntoEditor; </ins> } setTerminalInstance(instance: ITerminalInstance): void {
Code change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: V1.70.0 OS Version: Ubuntu 20.04 Steps to Reproduce: to latest V1.70.0 version of VSCode starship prompt for the bash shell. I have my starship prompt configured to update if the previous command execution failed for unknown reasons. After the latest update, every command execution seems to fail only in VSCode's terminal. Below is the expected behaviour, in a bash terminal: The screenshot of the same with colors: ! Now in the VSCode's terminal (running bash): (It shows the error condition even in a brand new instance of the terminal) A screenshot of the same with colors: ! This behaviour of always erroring out even for a successful command execution started today after VSCode auto updated to V1.70.0 Below is the information I got from menu: Version: 1.70.0 Commit: Date: 2022-08-04T04:38:48.541Z Electron: 18.3.5 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Linux x64 5.15.0-43-generic snap
Did you notice
, thanks for the prompt response! Yes, by disabling shell-integration, starship prompt started behaving as expected. Shall I close this issue or consider this a bug with shell-integration ?
I don't see why there was a need to enable Shell Integration by default, spent the last 2 hours trying to figure out what was wrong
This probably has nothing to do with starship (I have the same issue without starship). This is just a specific case of and should probably be closed as a duplicate

Related discussion:
text: __vsc_update_prompt <ins> __vsc_restore_exit_code() { return $1 } </ins> __vsc_prompt_cmd_original() { __vsc_status="$?" # Evaluate the original PROMPT_COMMAND similarly to how bash would normally
Code change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: V1.70.0 OS Version: Ubuntu 20.04 Steps to Reproduce: to latest V1.70.0 version of VSCode starship prompt for the bash shell. I have my starship prompt configured to update if the previous command execution failed for unknown reasons. After the latest update, every command execution seems to fail only in VSCode's terminal. Below is the expected behaviour, in a bash terminal: The screenshot of the same with colors: ! Now in the VSCode's terminal (running bash): (It shows the error condition even in a brand new instance of the terminal) A screenshot of the same with colors: ! This behaviour of always erroring out even for a successful command execution started today after VSCode auto updated to V1.70.0 Below is the information I got from menu: Version: 1.70.0 Commit: Date: 2022-08-04T04:38:48.541Z Electron: 18.3.5 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Linux x64 5.15.0-43-generic snap
Did you notice
, thanks for the prompt response! Yes, by disabling shell-integration, starship prompt started behaving as expected. Shall I close this issue or consider this a bug with shell-integration ?
I don't see why there was a need to enable Shell Integration by default, spent the last 2 hours trying to figure out what was wrong
This probably has nothing to do with starship (I have the same issue without starship). This is just a specific case of and should probably be closed as a duplicate

Related discussion:
text: eval "${cmd:-}" done else <ins> __vsc_restore_exit_code "${__vsc_status}" </ins> eval "${__vsc_original_prompt_command:-}" fi __vsc_precmd
Code change:
I noticed this in smoke test runner logs leading me to think that the type of the exit code is not a but an now?

Related discussion:
text: "git": { "name": "electron", "repositoryUrl": "https://github.com/electron/electron", <del> "commitHash": "a5cafd174d2027529d0b251e5b8e58da2b364e5b" </del> <ins> "commitHash": "b05ccd812e3bb3de5b1546a313e298961653e942" </ins> } }, "isOnlyProductionDependency": true, "license": "MIT", <del> "version": "19.0.11" </del> <ins> "version": "19.0.12" </ins> }, { "component": {
Code change:
I noticed this in smoke test runner logs leading me to think that the type of the exit code is not a but an now?

Related discussion:
text: "cssnano": "^4.1.11", "debounce": "^1.0.0", "deemon": "^1.4.0", <del> "electron": "19.0.11", </del> <ins> "electron": "19.0.12", </ins> "eslint": "8.7.0", "eslint-plugin-header": "3.1.1", "eslint-plugin-jsdoc": "^39.3.2",
Code change:
I noticed this in smoke test runner logs leading me to think that the type of the exit code is not a but an now?

Related discussion:
text: constructor(modulePath: string, args?: string[] | undefined, options?: UtilityProcessOptions); postMessage(channel: string, message: any, transfer?: Electron.MessagePortMain[]): void; kill(signal?: number | string): boolean; <del> on(event: 'exit', listener: (code: number | undefined) => void): this; </del> <ins> on(event: 'exit', listener: (event: Electron.Event, code: number) => void): this; </ins> on(event: 'spawn', listener: () => void): this; } }
Code change:
I noticed this in smoke test runner logs leading me to think that the type of the exit code is not a but an now?

Related discussion:
text: this._register(Event.fromNodeEventEmitter<void>(this._process, 'spawn')(() => { this._logService.info(`UtilityProcess<${this.id}>: received spawn event.`); })); <del> this._register(Event.fromNodeEventEmitter<number | undefined>(this._process, 'exit')((code: number | undefined) => { code = code || 0; </del> <ins> const onExit = Event.fromNodeEventEmitter<number>(this._process, 'exit', (_, code: number) => code); this._register(onExit((code: number) => { </ins> this._logService.info(`UtilityProcess<${this.id}>: received exit event with code ${code}.`); this._hasExited = true; this._onExit.fire({ pid: this._process!.pid!, code, signal: '' });
Code change:
I noticed this in smoke test runner logs leading me to think that the type of the exit code is not a but an now?

Related discussion:
text: resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@19.0.11: version "19.0.11" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.11.tgz#0c0a52abc08694fd38916d9270baf45bb7752a27" integrity sha512-GPM6C1Ze17/gR4koTE171MxrI5unYfFRgXQdkMdpWM2Cd55LMUrVa0QHCsfKpsaloufv9T65lsOn0uZuzCw5UA== </del> <ins> electron@19.0.12: version "19.0.12" resolved "https://registry.yarnpkg.com/electron/-/electron-19.0.12.tgz#73d11cc2a3e4dbcd61fdc1c39561e7a7911046e9" integrity sha512-GOvG0t2NCeJYIfmC3g/dnEAQ71k3nQDbRVqQhpi2YbsYMury0asGJwqnVAv2uZQEwCwSx4XOwOQARTFEG/msWw== </ins> dependencies: "@electron/get" "^1.14.1" "@types/node" "^16.11.26"
Code change:
Type: <bBug</bnotebook an image from the workspace into a markdown cell Bug this inserts the full uri, such as It should insert the relative path instead VS Code version: Code - Insiders 1.71.0-insider (Universal) (, 2022-08-10T05:18:38.020Z) OS version: Darwin x64 21.6.0 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<!-- generated by issue reporter --

Related discussion:
text: import * as path from 'path'; import * as vscode from 'vscode'; import * as URI from 'vscode-uri'; <ins> import { Schemes } from '../util/schemes'; </ins> const imageFileExtensions = new Set<string>([ '.bmp',
Code change:
Type: <bBug</bnotebook an image from the workspace into a markdown cell Bug this inserts the full uri, such as It should insert the relative path instead VS Code version: Code - Insiders 1.71.0-insider (Universal) (, 2022-08-10T05:18:38.020Z) OS version: Darwin x64 21.6.0 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<!-- generated by issue reporter --

Related discussion:
text: return; } <ins> const docUri = getParentDocumentUri(document); </ins> const snippet = new vscode.SnippetString(); uris.forEach((uri, i) => { <del> const mdPath = document.uri.scheme === uri.scheme ? encodeURI(path.relative(URI.Utils.dirname(document.uri).fsPath, uri.fsPath).replace(//g, '/')) </del> <ins> const mdPath = docUri.scheme === uri.scheme && docUri.authority === uri.authority ? encodeURI(path.relative(URI.Utils.dirname(docUri).fsPath, uri.fsPath).replace(//g, '/')) </ins> : uri.toString(false); const ext = URI.Utils.extname(uri).toLowerCase();