jiebi/CodeConvo huggingface dataset:
Code change:
Currently when using , ArrayBuffers just turn into an empty object. We should support these for efficient data transfer between extensions/extension hosts. We recently support for them on a protocol level, so support here should not be terribly hard...
I see two possible approaches to support this: this logic specifically for commands (or even just for a specific command). This is what we do for webviews for example: our implementation aware of array buffers instead of only supporting VSBuffers. Take a look at how is used in our rpc code as a starting point: The webview serialization logic I linked to above would probably be a good starting point for this

Related discussion:
text: } } <del> async $executeCommand<T>(id: string, args: any[], retry: boolean): Promise<T | undefined> { </del> <ins> async $executeCommand<T>(id: string, args: any[] | SerializableObjectWithBuffers<any[]>, retry: boolean): Promise<T | undefined> { if (args instanceof SerializableObjectWithBuffers) { args = args.value; } </ins> for (let i = 0; i < args.length; i++) { args[i] = revive(args[i]); }
Code change:
Currently when using , ArrayBuffers just turn into an empty object. We should support these for efficient data transfer between extensions/extension hosts. We recently support for them on a protocol level, so support here should not be terribly hard...
I see two possible approaches to support this: this logic specifically for commands (or even just for a specific command). This is what we do for webviews for example: our implementation aware of array buffers instead of only supporting VSBuffers. Take a look at how is used in our rpc code as a starting point: The webview serialization logic I linked to above would probably be a good starting point for this

Related discussion:
text: export interface MainThreadCommandsShape extends IDisposable { $registerCommand(id: string): void; $unregisterCommand(id: string): void; <del> $executeCommand<T>(id: string, args: any[], retry: boolean): Promise<T | undefined>; </del> <ins> $executeCommand<T>(id: string, args: any[] | SerializableObjectWithBuffers<any[]>, retry: boolean): Promise<T | undefined>; </ins> $getCommands(): Promise<string[]>; }
Code change:
Currently when using , ArrayBuffers just turn into an empty object. We should support these for efficient data transfer between extensions/extension hosts. We recently support for them on a protocol level, so support here should not be terribly hard...
I see two possible approaches to support this: this logic specifically for commands (or even just for a specific command). This is what we do for webviews for example: our implementation aware of array buffers instead of only supporting VSBuffers. Take a look at how is used in our rpc code as a starting point: The webview serialization logic I linked to above would probably be a good starting point for this

Related discussion:
text: import { IExtHostRpcService } from 'vs/workbench/api/common/extHostRpcService'; import { ISelection } from 'vs/editor/common/core/selection'; import { TestItemImpl } from 'vs/workbench/api/common/extHostTestingPrivateApi'; <ins> import { VSBuffer } from 'vs/base/common/buffer'; import { SerializableObjectWithBuffers } from 'vs/workbench/services/extensions/common/proxyIdentifier'; </ins> interface CommandHandler { callback: Function;
Code change:
Currently when using , ArrayBuffers just turn into an empty object. We should support these for efficient data transfer between extensions/extension hosts. We recently support for them on a protocol level, so support here should not be terribly hard...
I see two possible approaches to support this: this logic specifically for commands (or even just for a specific command). This is what we do for webviews for example: our implementation aware of array buffers instead of only supporting VSBuffers. Take a look at how is used in our rpc code as a starting point: The webview serialization logic I linked to above would probably be a good starting point for this

Related discussion:
text: if (Range.isIRange((obj as modes.Location).range) && URI.isUri((obj as modes.Location).uri)) { return extHostTypeConverter.location.to(obj); } <ins> if (obj instanceof VSBuffer) { return obj.buffer.buffer; } </ins> if (!Array.isArray(obj)) { return obj; }
Code change:
Currently when using , ArrayBuffers just turn into an empty object. We should support these for efficient data transfer between extensions/extension hosts. We recently support for them on a protocol level, so support here should not be terribly hard...
I see two possible approaches to support this: this logic specifically for commands (or even just for a specific command). This is what we do for webviews for example: our implementation aware of array buffers instead of only supporting VSBuffers. Take a look at how is used in our rpc code as a starting point: The webview serialization logic I linked to above would probably be a good starting point for this

Related discussion:
text: } else { // automagically convert some argument types <ins> let hasBuffers = false; </ins> const toArgs = cloneAndChange(args, function (value) { if (value instanceof extHostTypes.Position) { return extHostTypeConverter.Position.from(value);
Code change:
Currently when using , ArrayBuffers just turn into an empty object. We should support these for efficient data transfer between extensions/extension hosts. We recently support for them on a protocol level, so support here should not be terribly hard...
I see two possible approaches to support this: this logic specifically for commands (or even just for a specific command). This is what we do for webviews for example: our implementation aware of array buffers instead of only supporting VSBuffers. Take a look at how is used in our rpc code as a starting point: The webview serialization logic I linked to above would probably be a good starting point for this

Related discussion:
text: return extHostTypeConverter.location.from(value); } else if (extHostTypes.NotebookRange.isNotebookRange(value)) { return extHostTypeConverter.NotebookRange.from(value); <ins> } else if (value instanceof ArrayBuffer) { hasBuffers = true; return VSBuffer.wrap(new Uint8Array(value)); } else if (value instanceof Uint8Array) { hasBuffers = true; return VSBuffer.wrap(value); </ins> } if (!Array.isArray(value)) { return value;
Code change:
Currently when using , ArrayBuffers just turn into an empty object. We should support these for efficient data transfer between extensions/extension hosts. We recently support for them on a protocol level, so support here should not be terribly hard...
I see two possible approaches to support this: this logic specifically for commands (or even just for a specific command). This is what we do for webviews for example: our implementation aware of array buffers instead of only supporting VSBuffers. Take a look at how is used in our rpc code as a starting point: The webview serialization logic I linked to above would probably be a good starting point for this

Related discussion:
text: }); try { <del> const result = await this._proxy.$executeCommand<T>(id, toArgs, retry); </del> <ins> const result = await this._proxy.$executeCommand<T>(id, hasBuffers ? new SerializableObjectWithBuffers(toArgs) : toArgs, retry); </ins> return revive<any>(result); } catch (e) { // Rerun the command when it wasn't known, had arguments, and when retry
Code change:
This new capability allows the terminal to control when the tab description shows, so we can align the description in the terminal editor with how it shows up in a terminal panel tab.
To verify: Run a task, move the terminal to the editor area, check that the description shows up like it did in the panel In a terminal, change the directory, verify you see it in the tab description in the panel Move that to the terminal editor, make sure you see it there as well
Is this tooltip the task description? <img width="486" alt="image" src=""I think I'm a bit confused on how a task would be affected by a different terminal changing directories.
drag the terminal into the editor area and you should still see in the label of the tab.

Related discussion:
text: } override get capabilities(): EditorInputCapabilities { <del> return EditorInputCapabilities.Readonly | EditorInputCapabilities.Singleton | EditorInputCapabilities.CanDropIntoEditor; </del> <ins> return EditorInputCapabilities.Readonly | EditorInputCapabilities.Singleton | EditorInputCapabilities.CanDropIntoEditor | EditorInputCapabilities.ForceDescription; </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. --Version: 1.61.0 Commit: Date: 2021-10-07T18:11:58.853Z Electron: 13.5.1 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 20.6.0 Steps to Reproduce: the Terminal Sample from the vscode-extension-sample repository the a task that reuses a terminal. For example, I used a user task like: On the first run of the task the 'link' text will create a hover link correctly. If you re-run the task so the terminal has 2 (or more) runs of the task in the same terminal then the link will fail to detect correctly. Adding a breakpoint to there appears to be 1 call per execution of the task in the terminal. I think when the terminal is re-used it re-registers the link provider and if two link providers have overlapping links they both seem to fail (which is a known issue but due to this bug all link providers start failing if tasks are run multiple times).
Putting a breakpoint in the registerLinkProvider call for xterm (here ) I see multiple copies of all of the link providers: <img width="574" alt="Screen Shot 2021-10-12 at 9 15 30 AM" src="https://user-"

Related discussion:
text: private _widgetManager: TerminalWidgetManager | undefined; private _processCwd: string | undefined; private _standardLinkProviders: ILinkProvider[] = []; <del> private _standardLinkProvidersDisposables: IDisposable[] = []; </del> <ins> private _linkProvidersDisposables: IDisposable[] = []; </ins> constructor( private _xterm: Terminal,
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. --Version: 1.61.0 Commit: Date: 2021-10-07T18:11:58.853Z Electron: 13.5.1 Chrome: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Darwin x64 20.6.0 Steps to Reproduce: the Terminal Sample from the vscode-extension-sample repository the a task that reuses a terminal. For example, I used a user task like: On the first run of the task the 'link' text will create a hover link correctly. If you re-run the task so the terminal has 2 (or more) runs of the task in the same terminal then the link will fail to detect correctly. Adding a breakpoint to there appears to be 1 call per execution of the task in the terminal. I think when the terminal is re-used it re-registers the link provider and if two link providers have overlapping links they both seem to fail (which is a known issue but due to this bug all link providers start failing if tasks are run multiple times).
Putting a breakpoint in the registerLinkProvider call for xterm (here ) I see multiple copies of all of the link providers: <img width="574" alt="Screen Shot 2021-10-12 at 9 15 30 AM" src="https://user-"

Related discussion:
text: // Init winpty compat and link handler after process creation as they rely on the // underlying process OS this._processManager.onProcessReady((processTraits) => { <ins> // If links are ready, do not re-create the manager. if (this._areLinksReady) { return; } </ins> if (this._processManager.os === OperatingSystem.Windows) { xterm.setOption('windowsMode', processTraits.requiresWindowsMode || false); // Force line data to be sent when the cursor is moved, the main purpose for
Code change:
Issue Type: <bBug</bI'm using MacOS. After opening VSCode and getting into full-screen mode: If I use the integrated terminal of VSCode to create a new file, e.g.: VSCcode switches my screen to my previous workspace that causes interruption of work. Everytime I use to create a new file, I'll have to use + to move back to VSCode. VS Code version: Code 1.61.1 (, 2021-10-14T01:23:30.274Z) OS version: Darwin x64 20.6.0 Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (17)</summaryExtensionVersion ------ code-runner0.11.6 terminal0.0.10 go0.28.1 vscode-docker1.17.0 python2021.10. vscode-pylance2021.10.1 jupyter2021.9. jupyter-keymap1.0.0 jupyter-renderers1.0.3 remote-containers0.202.4 remote-ssh0.65.8 remote-ssh-edit0.65.8 remote-wsl0.58.2 vscode-remote-extensionpack0.21.0 vscode-yaml0.23.0 code-settings-sync3.4.3 open-in-browser2.0.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I am not sure if this could be a regression from the work we did to use the command.
I just built a version without the open cmd fix, but still saw the behaviour. I'm wondering if it could actually be caused by changes made during Edit: It seems reverting both commits fixes the issue.
It is unrelated to my changes. When I simply change this line to always go into the of : It does not reproduce anymore. Looks like when we are using , macOS does not really know whether a new window opens or an existing one reused. I feel this is a pretty bad regression actually.
I see that has fixed this bug and merged the PR. It seems like this is in (not sure what that means) but the issue still persists. I wonder when will this be fixed? In the next VSCode update? Thanks.
It should be fixed in our current latest stable release ().
Thanks, Just updated to today and I confirm that it's fixed.

Related discussion:
text: // similar to if the app was launched from the dock // https://github.com/microsoft/vscode/issues/102975 <del> const spawnArgs = ['-n'];				// -n: launches even when opened already </del> <ins> // The following args are for the open command itself, rather than for VS Code: // -n creates a new instance. //    Without -n, the open command re-opens the existing instance as-is. // -g starts the new instance in the background. //    Later, Electron brings the instance to the foreground. //    This way, Mac does not automatically try to foreground the new instance, which causes //    focusing issues when the new instance only sends data to a previous instance and then closes. const spawnArgs = ['-n', '-g']; // -a opens the given application. </ins> spawnArgs.push('-a', process.execPath); // -a: opens a specific application if (verbose) {
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?: n/a <!-- 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: latest OS Version: macOS 11.2.3 Steps to Reproduce: repo npm version < 14 or ≥ 17 to see this message message or just read the commit diff to see the problem
from check is for ≥ 17 but error message says to use ≤ 17, thus exactly v17 is both valid and invalid

Related discussion:
text: const majorNodeVersion = parseInt(/^(d+)./.exec(process.versions.node)[1]); if (majorNodeVersion < 14 || majorNodeVersion >= 17) { <del> console.error('033[1;31m*** Please use node.js versions >=14 and <=17.033[0;0m'); </del> <ins> console.error('033[1;31m*** Please use node.js versions >=14 and <17.033[0;0m'); </ins> err = true; }
Code change:
Copied from My workaround is export VSCODEGITASKPASSEXTRAARGS="--title=foobar" but the proper bugfix should happen in VSCode's GIT_ASKPASS implementation.
I experience the same problem, from the moment been released. Working through remote ssh the git processes stay open, without anything happening.
Still facing this issue on WSL.
Will be fixed in upcoming 1.62.2. Meanwhile a workaround is to and then manually
I can confirm that this is fixed after updating to 1.62.2 ().

Related discussion:
text: #!/bin/sh VSCODE_GIT_ASKPASS_PIPE=`mktemp` <del> ELECTRON_RUN_AS_NODE="1" VSCODE_GIT_ASKPASS_PIPE="$VSCODE_GIT_ASKPASS_PIPE" "$VSCODE_GIT_ASKPASS_NODE" "$VSCODE_GIT_ASKPASS_EXTRA_ARGS" "$VSCODE_GIT_ASKPASS_MAIN" $* </del> <ins> ELECTRON_RUN_AS_NODE="1" VSCODE_GIT_ASKPASS_PIPE="$VSCODE_GIT_ASKPASS_PIPE" "$VSCODE_GIT_ASKPASS_NODE" "$VSCODE_GIT_ASKPASS_MAIN" $VSCODE_GIT_ASKPASS_EXTRA_ARGS $* </ins> cat $VSCODE_GIT_ASKPASS_PIPE rm $VSCODE_GIT_ASKPASS_PIPE
Code change:
! It could be that I caused this, but I doubt it (injected text has nothing to do with the gutter, maybe they shared a CSS rule).
I can reproduce but I'm not aware of any changes in that area from the debug side.
I would like to work on this issue!
Before fixing anything we should do a "git bisect" to find the commit that broke this.
commit . it should
thanks for pointing out the commit! If you like, you can provide a PR, that would be awesome!
PR

Related discussion:
text: margin-top: -1px; } <ins> .codicon-debug-breakpoint.codicon-debug-stackframe-focused::after, .codicon-debug-breakpoint.codicon-debug-stackframe::after { content: 'eb8a'; position: absolute; } </ins> .monaco-editor .debug-top-stack-frame-column { font: normal normal normal 16px/1 codicon; text-rendering: auto;
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 In make a new keybinding: Intellisense shows many arg keys that are inaccurate or not implemented. Here is what I get for intellisense: These appear to be the correct and implemented args to this command: Version: 1.63.0-insider (user setup) Commit: Date: 2021-12-02T05:15:40.605Z Electron: 13.5.2 Chromium: 91.0.4472.164 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0.
Related:
This issue persists as of vscode I was going to open an bug issue mentioning that some params were not working... when in fact I was using the ones suggested by the intellisense e.g. instead of . A while back I opened: about how the command does not resolve variables whereas does. Also related I guess needs some love to be more consistent feature-wise with .

Related discussion:
text: properties: { searchString: { type: 'string' }, replaceString: { type: 'string' }, <del> regex: { type: 'boolean' }, regexOverride: { type: 'number', description: nls.localize('actions.find.isRegexOverride', 'Overrides "Use Regular Expression" flag.nThe flag will not be saved for the future.n0: Do Nothingn1: Truen2: False') }, wholeWord: { type: 'boolean' }, wholeWordOverride: { type: 'number', description: nls.localize('actions.find.wholeWordOverride', 'Overrides "Match Whole Word" flag.nThe flag will not be saved for the future.n0: Do Nothingn1: Truen2: False') }, matchCase: { type: 'boolean' }, matchCaseOverride: { type: 'number', description: nls.localize('actions.find.matchCaseOverride', 'Overrides "Math Case" flag.nThe flag will not be saved for the future.n0: Do Nothingn1: Truen2: False') }, </del> <ins> isRegex: { type: 'boolean' }, matchWholeWord: { type: 'boolean' }, isCaseSensitive: { type: 'boolean' }, </ins> preserveCase: { type: 'boolean' }, <del> preserveCaseOverride: { type: 'number', description: nls.localize('actions.find.preserveCaseOverride', 'Overrides "Preserve Case" flag.nThe flag will not be saved for the future.n0: Do Nothingn1: Truen2: False') }, </del> findInSelection: { type: 'boolean' }, } }
Code change:
I do not see the notification toast when I select "New Terminal" from command palette. But I see this issue that the OP reported I think: ! ! Originally posted by in
I see this problem: Start a new terminal - full screen Drag to bottom or right = non-functional If you split the panel right, it is fine
Reproes only when you have more than one terminal in the editor area
Can do it with a single terminal, clean open of VSCode (mac), no other windows. !
Thanks, I specifically meant when dragging and dropping into the panel.
/verified second terminal is no longer blank

Related discussion:
text: this._container = undefined; } attachToElement(container: HTMLElement): Promise<void> | void { // The container did not change, do nothing if (this._container === container) {
Code change:
I do not see the notification toast when I select "New Terminal" from command palette. But I see this issue that the OP reported I think: ! ! Originally posted by in
I see this problem: Start a new terminal - full screen Drag to bottom or right = non-functional If you split the panel right, it is fine
Reproes only when you have more than one terminal in the editor area
Can do it with a single terminal, clean open of VSCode (mac), no other windows. !
Thanks, I specifically meant when dragging and dropping into the panel.
/verified second terminal is no longer blank

Related discussion:
text: this._attachBarrier.open(); <del> this.xterm?.attachToElement(container); </del> // Attach has not occurred yet if (!this._wrapperElement) { return this._attachToElement(container); } <ins> this.xterm?.attachToElement(this._wrapperElement); </ins> // The container changed, reattach this._container = container;
Code change:
allows extensions to disable the "Open Preview" button in markdown files. This option should also disable the "Open Preview" button in the context menus. ! Originally posted by in
/verified In stable: ! In insiders: !

Related discussion:
text: "explorer/context": [ { "command": "markdown.showPreview", <del> "when": "resourceLangId == markdown", </del> <ins> "when": "resourceLangId == markdown && !hasCustomMarkdownPreview", </ins> "group": "navigation" } ], "editor/title/context": [ { "command": "markdown.showPreview", <del> "when": "resourceLangId == markdown", </del> <ins> "when": "resourceLangId == markdown && !hasCustomMarkdownPreview", </ins> "group": "1_open" } ],