jiebi/CodeConvo huggingface dataset:
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. --<!-- 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.79.0-insider OS Version: macOS 12.6.3 I am working on a file explorer tree view extension and doesn't work properly if is 2 or 3. When expand is 3 only the first level 3 folder expands. I have checked and doesn't get called for the rest of the level 3 folders. If I call again with the rest of the level 3 folders expand. When I use with 2 or 3 on a large folder (hundreds of items) the promise never fulfills even though the folder expands (at least up to level 2). I don't get any error in any of the two cases.
can you share a minimal example that reproduces this issue?
Sure thing, here you have it:
Thank you for the repro repo!
No problem, thanks for the fix!

Related discussion:
text: } try { itemOrItems = Array.isArray(itemOrItems) ? itemOrItems : [itemOrItems]; <del> await Promise.all(itemOrItems.map(element => { return tree.expand(element, false); })); </del> <ins> for (const element of itemOrItems) { await tree.expand(element, false); } </ins> } catch (e) { // The extension could have changed the tree during the reveal. // Because of that, we ignore errors.
Code change:
Callstack is similar to the one mentioned in but the issue remains First failure Second failure
The logs read very normal, we literally hit the 2min timeout. Since these tests do double the work (start VS Code 2 times), I will see if increasing the timeout helps.

Related discussion:
text: export function setup(ensureStableCode: () => string | undefined, logger: Logger) { describe('Data Loss (insiders -> insiders)', function () { <ins> // Double the timeout since these tests involve 2 startups this.timeout(4 * 60 * 1000); </ins> let app: Application | undefined = undefined; // Shared before/after handling
Code change:
Callstack is similar to the one mentioned in but the issue remains First failure Second failure
The logs read very normal, we literally hit the 2min timeout. Since these tests do double the work (start VS Code 2 times), I will see if increasing the timeout helps.

Related discussion:
text: }); describe('Data Loss (stable -> insiders)', function () { <ins> // Double the timeout since these tests involve 2 startups this.timeout(4 * 60 * 1000); </ins> let insidersApp: Application | undefined = undefined; let stableApp: Application | undefined = undefined;
Code change:
I'm seeing some flickering here, just Write a multi-line commit message cmd+enter to commit !

Related discussion:
text: const inputWidget = this.instantiationService.createInstance(SCMInputWidget, inputElement, this.overflowWidgetsDomNode); templateDisposable.add(inputWidget); <del> return { inputWidget, elementDisposables: new DisposableStore(), templateDisposable }; </del> <ins> return { inputWidget, inputWidgetHeight: InputRenderer.DEFAULT_HEIGHT, elementDisposables: new DisposableStore(), templateDisposable }; </ins> } renderElement(node: ITreeNode<ISCMInput, FuzzyScore>, index: number, templateData: InputTemplate): void {
Code change:
I'm seeing some flickering here, just Write a multi-line commit message cmd+enter to commit !

Related discussion:
text: // Remember widget this.inputWidgets.set(input, templateData.inputWidget); templateData.elementDisposables.add({ <del> dispose: () => { this.inputWidgets.delete(input); this.contentHeights.delete(input); } </del> <ins> dispose: () => this.inputWidgets.delete(input) </ins> }); // Widget cursor selections
Code change:
I'm seeing some flickering here, just Write a multi-line commit message cmd+enter to commit !

Related discussion:
text: // Rerender the element whenever the editor content height changes const onDidChangeContentHeight = () => { const contentHeight = templateData.inputWidget.getContentHeight(); <del> const lastContentHeight = this.contentHeights.get(input)!; </del> this.contentHeights.set(input, contentHeight); <del> if (lastContentHeight !== contentHeight) { </del> <ins> if (templateData.inputWidgetHeight !== contentHeight) { </ins> this.updateHeight(input, contentHeight + 10); <ins> templateData.inputWidgetHeight = contentHeight; </ins> templateData.inputWidget.layout(); } };
Code change:
I see this in the console log when I reload vscode insiders window: <img width="1463" alt="image" src=""vscode insiders with the vscode welcome page open (I can't repro without the welcome page) window and you'll see the errors in the console logs

Related discussion:
text: override async setInput(newInput: GettingStartedInput, options: IEditorOptions | undefined, context: IEditorOpenContext, token: CancellationToken) { this.container.classList.remove('animatable'); this.editorInput = newInput; <del> await this.lifecycleService.when(LifecyclePhase.Restored); </del> await super.setInput(newInput, options, context, token); <ins> await this.lifecycleService.when(LifecyclePhase.Restored); </ins> await this.buildCategoriesSlide(); if (this.shouldAnimate()) { setTimeout(() => this.container.classList.add('animatable'), 0);
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: Steps to Reproduce: an invalid decoration in warning in ext host logs that says instead of the extension name:
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.78.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!

Related discussion:
text: } result[id] = <DecorationData>[data.propagate, data.tooltip, data.badge, data.color]; } catch (e) { <del> this._logService.warn(`INVALID decoration from extension '${extensionId}': ${e}`); </del> <ins> this._logService.warn(`INVALID decoration from extension '${extensionId.identifier.value}': ${e}`); </ins> } } catch (err) { this._logService.error(err);
Code change:
Testing ! !
This is because of the same problem that caused
appears to be closed now, does that mean this has been fixed?
No, this issue is about fish acting atypical in that it applies the environment before is applied. This is because of how the automatic injection works in fish via an environment variable. Still not sure how we can handle this.
Discussed offline, maybe we could use the first pre exec hook in fish to run shell integration, instead of .
Nice !

Related discussion:
text: end set -e VSCODE_PATH_PREFIX <del> # Apply EnvironmentVariableCollections if needed if test -n "$VSCODE_ENV_REPLACE" set ITEMS (string split : $VSCODE_ENV_REPLACE) for B in $ITEMS set split (string split = $B) set -gx "$split[1]" (echo -e "$split[2]") </del> <ins> set -g __vsc_applied_env_vars 0 function __vsc_apply_env_vars if test $__vsc_applied_env_vars -eq 1; return </ins> end <del> set -e VSCODE_ENV_REPLACE end if test -n "$VSCODE_ENV_PREPEND" set ITEMS (string split : $VSCODE_ENV_PREPEND) for B in $ITEMS set split (string split = $B) set -gx "$split[1]" (echo -e "$split[2]")"$$split[1]" # avoid -p as it adds a space </del> <ins> set -l __vsc_applied_env_vars 1 # Apply EnvironmentVariableCollections if needed if test -n "$VSCODE_ENV_REPLACE" set ITEMS (string split : $VSCODE_ENV_REPLACE) for B in $ITEMS set split (string split = $B) set -gx "$split[1]" (echo -e "$split[2]") end set -e VSCODE_ENV_REPLACE </ins> end <del> set -e VSCODE_ENV_PREPEND end if test -n "$VSCODE_ENV_APPEND" set ITEMS (string split : $VSCODE_ENV_APPEND) for B in $ITEMS set split (string split = $B) set -gx "$split[1]" "$$split[1]"(echo -e "$split[2]") # avoid -a as it adds a space </del> <ins> if test -n "$VSCODE_ENV_PREPEND" set ITEMS (string split : $VSCODE_ENV_PREPEND) for B in $ITEMS set split (string split = $B) set -gx "$split[1]" (echo -e "$split[2]")"$$split[1]" # avoid -p as it adds a space end set -e VSCODE_ENV_PREPEND end if test -n "$VSCODE_ENV_APPEND" set ITEMS (string split : $VSCODE_ENV_APPEND) for B in $ITEMS set split (string split = $B) set -gx "$split[1]" "$$split[1]"(echo -e "$split[2]") # avoid -a as it adds a space end set -e VSCODE_ENV_APPEND </ins> end <del> set -e VSCODE_ENV_APPEND </del> end # Handle the shell integration nonce
Code change:
Testing ! !
This is because of the same problem that caused
appears to be closed now, does that mean this has been fixed?
No, this issue is about fish acting atypical in that it applies the environment before is applied. This is because of how the automatic injection works in fish via an environment variable. Still not sure how we can handle this.
Discussed offline, maybe we could use the first pre exec hook in fish to run shell integration, instead of .
Nice !

Related discussion:
text: # Sent at the start of the prompt. # Marks the beginning of the prompt (and, implicitly, a new line). function __vsc_fish_prompt_start <ins> # Applying environment variables is deferred to after config.fish has been # evaluated __vsc_apply_env_vars </ins> __vsc_esc A end
Code change:
On the notebook toolbar we have multiple sections of actions, and the first two are core sections: insert and execution. The Insert section is very stable and it always contains two actions: insert code and insert markdown. However the execution section has actions from both VS Code core and Jupyter extension, and with a mix use of visibility and enablement, it is not user friendly and often leads to mis-clicks. Initial state <img width="811" alt="image" src=""Start execution <img width="884" alt="image" src=""Execution fails <img width="903" alt="image" src=""Execution succeeds <img width="810" alt="image" src=""Initial state <img width="657" alt="image" src=""Start execution <img width="867" alt="image" src=""Execution fails <img width="728" alt="image" src=""Execution succeeds <img width="625" alt="image" src=""As shown above, currently only is using enablement while all others are using visibility, which can lead to change of positions for the actions and often when users want to interrupt or restart the kernel, their position changes and users click on wrong actions. cc
What are users misclicking on? From my memory, I remember Go To vs Restart. I think that "Restart" has a confirm dialog, are there other destructive actions that should also have a confirm dialog? Or, should we use enablement and have all actions always visible?
For Jupyter kernel, I ran into Go To vs Restart and sometimes Restart vs next action on the toolbar (since Go To disappears), and for non Jupyter, it's Interrupt vs Clear all outputs. It might be hard to enforce that but we could probably at least ensure the ones that are always visible won't change their position when the execution state changes. For example, if Go To only shows at the end in this group, and Run All is always replaced by "Interrupt" or "Stop", then it's less likely to mis-click.

Related discussion:
text: group: 'navigation/execute', when: ContextKeyExpr.and( executeNotebookCondition, <del> ContextKeyExpr.or(NOTEBOOK_INTERRUPTIBLE_KERNEL.toNegated(), NOTEBOOK_HAS_SOMETHING_RUNNING.toNegated()), </del> <ins> ContextKeyExpr.or( NOTEBOOK_INTERRUPTIBLE_KERNEL.toNegated(), NOTEBOOK_HAS_SOMETHING_RUNNING.toNegated(), ), ContextKeyExpr.and(NOTEBOOK_HAS_SOMETHING_RUNNING, NOTEBOOK_INTERRUPTIBLE_KERNEL.toNegated())?.negate(), </ins> ContextKeyExpr.equals('config.notebook.globalToolbar', true) ) }
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.77.3 OS Version: Windows 11 Steps to Reproduce: a git repository a file with brackets in the name, e.g. the file in the git tab and add it to the file Desired behavior: The filename is to the such that the file is ignored Observed behavior: The file name is to but it is not ignored. This is because the syntax of does not interpret brackets literally. To ignore a filename that includes brackets requires escaping brackets with backslashes. gitignore after step 3: for desired effect should be: Proposed fix: Pre-process file names to to escape special characters.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.79.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!

Related discussion:
text: return await this.run(Operation.Ignore, async () => { const ignoreFile = `${this.repository.root}${path.sep}.gitignore`; const textToAppend = files <del> .map(uri => relativePath(this.repository.root, uri.fsPath).replace(//g, '/')) </del> <ins> .map(uri => relativePath(this.repository.root, uri.fsPath) .replace(/|[/g, match => match === '' ? '/' : `${match}`)) </ins> .join('n'); const document = await new Promise(c => fs.exists(ignoreFile, c))
Code change:
Looks like we have broad support for . Static initialisers are the slight exception as they are only in Safari since ~2months. We might want to special case them, but otherwise we should be good to go:
On native privates: using them will be faster than weak-map-privates but slower than normal properties (much, much slower for Safari):
Some, perf number for some new API native privates - , faster than WeakMap privates but slower than conventional privates slower than []-access needs which need broader adoption because of semantic change.
Upstream issues for private property performance v8 - Webkit -

Related discussion:
text: tsx: false, decorators: true }, <del> target: 'es2020', </del> <ins> target: 'es2022', </ins> loose: false, minify: { compress: false,
Code change:
Looks like we have broad support for . Static initialisers are the slight exception as they are only in Safari since ~2months. We might want to special case them, but otherwise we should be good to go:
On native privates: using them will be faster than weak-map-privates but slower than normal properties (much, much slower for Safari):
Some, perf number for some new API native privates - , faster than WeakMap privates but slower than conventional privates slower than []-access needs which need broader adoption because of semantic change.
Upstream issues for private property performance v8 - Webkit -

Related discussion:
text: "./vs/*" ] }, <ins> "target": "es2022", "useDefineForClassFields": false, </ins> "lib": [ <del> "ES2016", "ES2017.Object", "ES2017.String", "ES2017.Intl", "ES2017.TypedArrays", "ES2018.AsyncIterable", "ES2018.AsyncGenerator", "ES2018.Promise", "ES2018.Regexp", "ES2018.Intl", "ES2019.Array", "ES2019.Object", "ES2019.String", "ES2019.Symbol", "ES2020.BigInt", "ES2020.Promise", "ES2020.String", "ES2020.Symbol.WellKnown", "ES2020.Intl", "ES2021.Promise", "ES2021.String", "ES2021.WeakRef", </del> <ins> "ES2022", </ins> "DOM", "DOM.Iterable", "WebWorker.ImportScripts"
Code change:
Looks like we have broad support for . Static initialisers are the slight exception as they are only in Safari since ~2months. We might want to special case them, but otherwise we should be good to go:
On native privates: using them will be faster than weak-map-privates but slower than normal properties (much, much slower for Safari):
Some, perf number for some new API native privates - , faster than WeakMap privates but slower than conventional privates slower than []-access needs which need broader adoption because of semantic change.
Upstream issues for private property performance v8 - Webkit -

Related discussion:
text: "allowJs": true, "resolveJsonModule": true, "outDir": "../out/vs", <del> "target": "es2021", </del> "types": [ "keytar", "mocha",
Code change:
Looks like we have broad support for . Static initialisers are the slight exception as they are only in Safari since ~2months. We might want to special case them, but otherwise we should be good to go:
On native privates: using them will be faster than weak-map-privates but slower than normal properties (much, much slower for Safari):
Some, perf number for some new API native privates - , faster than WeakMap privates but slower than conventional privates slower than []-access needs which need broader adoption because of semantic change.
Upstream issues for private property performance v8 - Webkit -

Related discussion:
text: export class ExtractError extends Error { readonly type?: ExtractErrorType; <del> readonly cause: Error; </del> constructor(type: ExtractErrorType | undefined, cause: Error) { let message = cause.message;
Code change:
Looks like we have broad support for . Static initialisers are the slight exception as they are only in Safari since ~2months. We might want to special case them, but otherwise we should be good to go:
On native privates: using them will be faster than weak-map-privates but slower than normal properties (much, much slower for Safari):
Some, perf number for some new API native privates - , faster than WeakMap privates but slower than conventional privates slower than []-access needs which need broader adoption because of semantic change.
Upstream issues for private property performance v8 - Webkit -

Related discussion:
text: export abstract class ErrorHandler { <del> static { </del> <ins> static async installEarlyHandler(accessor: ServicesAccessor): Promise<void> { </ins> // increase number of stack frames (from 10, https://github.com/v8/v8/wiki/Stack-Trace-API) Error.stackTraceLimit = 100; <del> } static async installEarlyHandler(accessor: ServicesAccessor): Promise<void> { </del> // does NOT dependent of extension information, can be installed immediately, and simply forwards // to the log service and main thread errors const logService = accessor.get(ILogService);
Code change:
I had a "Testing" profile with various remote extensions installed. I deleted it (while being in it) and then recreated it empty. I still found all remote menu contributions even though the profile should have been empty. Maybe switching profiles should ask to reload the window when extensions require so? Steps to Reproduce: fresh user data dir, fresh extensions dir create an empty profile install SSH extension notice how the remote explorer view appears delete the profile notice how the remote explorer view is still there, same as the status bar entry for remote
Another case from is interesting: I do not think using a profile is a good idea for when extensions require a window reload to be disabled. So you need to then probably ask the user to reload the window or do it automatically.
AFAIK every extension requires a window reload after being disabled (except for package-json only extensions). We cannot unload code from extensions and cannot enforce them not doing anything anymore. There we always reload the window or at least the extension host
While switching profiles we restart extension host. You say this is not enough to unload extensions? Also while trusting/untrusting a workspace.
No, only those that are activate with code loaded. Here are steps: fresh user data dir, fresh extensions dir create an empty profile install SSH extension notice how the remote explorer view appears delete the profile notice how the remote explorer view is still there, same as the status bar entry for remote
I see this can be reproduced with above steps. But Remote Explorer view disappears with switching profile. So I think this is a bug (either in views or profiles) when profile is deleted. But status bar entries always appear.

Related discussion:
text: private async initialize(): Promise<void> { await this.extensionsScannerService.initializeDefaultProfileExtensions(); <del> await this.onDidChangeProfiles(this.userDataProfilesService.profiles, []); </del> <ins> await this.onDidChangeProfiles(this.userDataProfilesService.profiles); </ins> this.registerListeners(); await this.uninstallExtensionsNotInProfiles(); } private registerListeners(): void { <del> this._register(this.userDataProfilesService.onDidChangeProfiles(e => this.onDidChangeProfiles(e.added, e.removed))); </del> <ins> this._register(this.userDataProfilesService.onDidChangeProfiles(e => this.onDidChangeProfiles(e.added))); </ins> this._register(this.extensionsProfileScannerService.onAddExtensions(e => this.onAddExtensions(e))); this._register(this.extensionsProfileScannerService.onDidAddExtensions(e => this.onDidAddExtensions(e))); this._register(this.extensionsProfileScannerService.onRemoveExtensions(e => this.onRemoveExtensions(e)));