jiebi/CodeConvo huggingface dataset:
Change:
// 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) {

Discussion:
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.
Change:
.monaco-workbench .part.editor>.content .gettingStartedContainer .gettingStartedSlide .getting-started-category .featured .featured-icon { top: -30px; left: 4px; <del> font-size: 12pt; </del> <ins> font-size: 14px; </ins> } .monaco-workbench .part.editor>.content .gettingStartedContainer .gettingStartedSlide .getting-started-category .codicon.hide-category-button {

Discussion:
<img width="626" alt="CleanShot 2022-10-07 at 10 18 27 src="https://user-"
Change:
return true; } <ins> // with the command center enabled, we should always show if (this.configurationService.getValue<boolean>('window.commandCenter')) { return true; } </ins> // remaining behavior is based on menubar visibility switch (getMenuBarVisibility(this.configurationService)) { case 'classic':

Discussion:
<!-- 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/No <!-- 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.68 OS Version: Browser (windows) Steps to Reproduce: on command center in settings. Command center is not visible. If changing menu from compact to visible it is shown. In desktop it is shown in compact mode.
We have revisited our decision and reverted this change. There is a lengthly discussion in In our "defence", the classic menu rendering has gotten more responsive and will become the compact burger when space is rare. I think we can tweak this further for an even better experience https://user-
I don't really get this decision. This is not the default behavior, so if I decide to set it up like this, why can't I just have the command center without the other menus? It's like you do not support a certain setup which if a user like, why not provide him that? I don't really use most of the menu items, if I need something I just use the command center to find the command. why does it have to be all or nothing?
The title bar showing if CC is enabled has been brought back with other tweaks to improve the experience
Change:
throw toExtensionManagementError(new CancellationError()); } <del> const { local, verificationStatus } = await this.extractExtensionFn(this.operation, token); this._verificationStatus = verificationStatus; </del> <ins> if (!local) { const result = await this.extractExtensionFn(this.operation, token); local = result.local; this._verificationStatus = result.verificationStatus; } </ins> if (this.uriIdentityService.extUri.isEqual(this.userDataProfilesService.defaultProfile.extensionsResource, this.options.profileLocation)) { try {

Discussion:
Steps to Reproduce: an pre-release version of an extension to release version and restart extension host back to pre-release version and refresh extensions view Extension is still release version
Change:
) { } showHover(options: IHoverDelegateOptions, focus?: boolean): IHoverWidget | undefined { <ins> // Only show the hover hint if the content is of a decent size const showHoverHint = ( options.content instanceof HTMLElement ? options.content.textContent ?? '' : typeof options.content === 'string' ? options.content : options.content.value ).length > 20; </ins> return this.hoverService.showHover({ ...options, persistence: { hideOnKeyDown: false, }, appearance: { <del> showHoverHint: true, </del> <ins> showHoverHint, </ins> skipFadeInAnimation: true, }, }, focus);

Discussion:
Type: <bBug</bWhat does this mean / do? ! VS Code version: Code 1.84.0 (, 2023-11-01T11:29:04.398Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
Apparently from by and present since 1.78.
this should only be showing up for the quick pick item hovers, not the actions which have a small amount of content.
Change:
} const innerLineNumberHTML = document.createElement('span'); <del> innerLineNumberHTML.innerText = this._lineNumber.toString(); </del> <ins> const lineNumberOption = this._editor.getOption(EditorOption.lineNumbers); if (lineNumberOption.renderType === RenderLineNumbersType.On || lineNumberOption.renderType === RenderLineNumbersType.Interval && this._lineNumber % 10 === 0) { innerLineNumberHTML.innerText = this._lineNumber.toString(); } else if (lineNumberOption.renderType === RenderLineNumbersType.Relative) { innerLineNumberHTML.innerText = Math.abs(this._lineNumber - this._editor.getPosition().lineNumber).toString(); } </ins> innerLineNumberHTML.className = 'sticky-line-number'; innerLineNumberHTML.style.lineHeight = `${lineHeight}px`; innerLineNumberHTML.style.width = `${layoutInfo.lineNumbersWidth}px`;

Discussion:
Type: <bBug</bTesting down in a TypeScript function ! Note that, In the screenshot, is actually at line 1344, the gutter doesn't have enough space for 4 numbers. Also, the visual separation between sticky lines and normal lines looks too subtle for me. VS Code version: Code - Insiders 1.70.0-insider (, 2022-07-29T10:47:14.408Z) OS version: WindowsNT x64 10.0. Modes: Remote OS version: Linux x64 5.10.102.1-microsoft-standard-WSL2 <details<summarySystem Info</summary </details<details<summaryExtensions (18)</summaryExtensionVersion ------ Bookmarks13.3.1 remotehub0.39. remote-containers0.243.0 remote-ssh0.85. remote-ssh-edit0.80.0 remote-wsl0.66.3 remote-repositories0.16.0 material-icon-theme4.19.0 material-theme3.15.2 vscode-eslint2.2.6 gitlens12.1.2 prettier-vscode9.5.0 copilot-nightly1.36.6347 js-debug-nightly2022.7.2717 abracadabra6.14.4 vscode-jest4.6.0 prisma4.1.0 code-spell-checker2.3.4 </details<!-- generated by issue reporter --
Change:
} getAriaLabel(element: IExpression): string { <del> return nls.localize({ key: 'variableAriaLabel', comment: ['Do not translate placholders. Placeholders are name and value of a variable.'] }, "{0}, value {1}, variables, debug", element.name, element.value); </del> <ins> return nls.localize({ key: 'variableAriaLabel', comment: ['Do not translate placeholders. Placeholders are name and value of a variable.'] }, "{0}, value {1}, variables, debug", element.name, element.value); </ins> } }

Discussion:
nls.localize() generally involves human visible output. Technically there are 2-3 arguments and the main human facing one is the second. The first argument is often treated as an "opaque" string, but in most systems, it's used to communicate to localizers, so, to some extent, there is value in not having misspellings there either. I can split out the identifiers if requested... Does this issue occur when all extensions are disabled?: Yes
can you provide me with more details about this. We use Transifex to translate our strings and the system contains both the value and the key.
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Change:
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 {

Discussion:
I'm seeing some flickering here, just Write a multi-line commit message cmd+enter to commit !
Change:
}; private _activeTasks: IStringDictionary<IActiveTerminalData>; <del> private _instances: IStringDictionary<InstanceManager>; </del> private _busyTasks: IStringDictionary<Task>; private _terminals: IStringDictionary<ITerminalData>; private _idleTaskTerminals: LinkedMap<string, string>;

Discussion:
<!-- 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.78.0 and older and (with slightly different behavior) insiders as of 5/4/2023 OS Version: MacOS 13.3.1 (a) Steps to Reproduce: Use these commands to produce and launch a suitable project: First bug: in either 1.78.0 or the nightly, use to launch , then hit Cmd-Shift-B to launch . You end up with two copies of running, when it should have an implicit of 1. Hit Cmd-Shift-B again, and it will tell you you've hit the instance limit. The problem here is that dependent tasks don't count towards the instance limit. Second bug: Now add to , and repeat the above. There is no change in the nightly (as you might expect), but surprisingly 1.78.0 now reports that it can't start a second copy. But thats just a bug; if you change it to and repeat, 1.78.0, still tells you it can't launch a second copy. This bug was fixed by , so I'm just including it for completeness. Third bug: Add to . Now hit Cmd-Shift-B to launch , then use to launch . will (correctly) re-use the already running task, rather than launching a new one. Now kill all the terminals (to make the next step less confusing). Hit Cmd-Shift-B to launch sleeper, wait 5 seconds, and hit Cmd-Shift-B again, wait another 5 seconds for the first task to finish, and then run .

Now, although the second task is still running, starts a new one. The issue here is that when looking for an existing dependent task, uses the task's , which only matches the first instance of a task with greater than 1 (and here, that task has already finished).
Change:
return; } <ins> const whitespacesOnly = text.length && !text.replace(/s/g, ''); if (whitespacesOnly) { return { message: localize('commitMessageWhitespacesOnlyWarning', "Current commit message only contains whitespaces"), type: SourceControlInputBoxValidationType.Warning }; } </ins> let start = 0, end; let match: RegExpExecArray | null; const regex = /r?n/g;

Discussion:
you can commit "a line break as a message" to git
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.565 --- <!-- score: 0.484 --<!-- potentialduplicatescomment --
Hi I would like to take up this task. Could you point me to a starting point?
We don't really have to prevent it, but we can warn the user about it. Over there is some validation of the input box happening (for when lines are too long, for example). Maybe we can also warn the user that the current input isn't valid when all he does is enter a bunch of line breaks in it. But there should be no warning for when the box is empty, otherwise it would be too much "in the user's face".
Change:
await mkdirp(parentPath); try { <del> await this.exec(parentPath, ['clone', url.includes(' ') ? encodeURI(url) : url, folderPath], { cancellationToken }); </del> <ins> await this.exec(parentPath, ['clone', url.includes(' ') ? encodeURI(url) : url, folderPath, '--progress'], { cancellationToken, progress }); </ins> } catch (err) { if (err.stderr) { err.stderr = err.stderr.replace(/^Cloning.+$/m, '').trim();

Discussion:
<!-- Please search existing issues to avoid creating duplicates. --When downloading a GIT repository should indicate the percentage of download. <!-- Describe the feature you'd like. --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.484 --<!-- potentialduplicatescomment --
I would like to take this.
Change:
editPresentation?: EditPresentationTypes; defaultValueSource?: string | IExtensionInfo; isLanguageTagSetting?: boolean; <ins> categoryOrder?: number; categoryLabel?: string; </ins> } export interface IExtensionSetting extends ISetting {

Discussion:
Tested on Insiders Build 1.65.0 and Build 1.64.2. If an extension's settings are viewed, the presentation order is respected, but _only if the "Search settings" bar is empty. If the search bar contains anything, including the name of the extension (matching all settings for that extension), the presentation order is alphabetical. Given that the presentation can still be controlled by the selected extension name in the left menu, it would seem logically possible to respect the sort ordering within an extension settings group. Examples: Following ordering (search area blank): ! Not following ordering: !
Verification steps: or write an extension with settings where the settings group and the individual settings use fields to determine the order. An example is at Also make the setting keys similar so that they can show up under the same search query. the extension, navigate to the Settings editor, and clear the search widget. that the settings for that extension are displayed in the expected order. a query to the search widget such that those extension settings still show up. that the filtered settings for that extension show up in the same order as in step 3.
Tested just now on LGTM
Change:
/** * The icon for the task */ <del> icon: { id: string; color?: string } | undefined; </del> <ins> icon: { id?: string; color?: string } | undefined; </ins> public constructor(id: string, source: IExtensionTaskSource, label: string, type: string | undefined, defines: KeyedTaskIdentifier, command: ICommandConfiguration, hasDefinedMatchers: boolean, runOptions: IRunOptions,

Discussion:
Testing I the following to the "Core - Build" task in this repo: The color shows in the "Run Task" quick pick, but not in the terminal tabs (I tried reloading, but still no color). !
the color will only take effect the next time you run the task - don't think it's worth listening to the config and updating. we don't do that for existing terminals either when an icon or color is set for their profile <img width="1291" alt="Screen Shot 2022-06-28 at 12 06 04 PM" src="https://user-"
Alex mentioned , I actually reproduced the icon and color not applying when testing also
I'm guessing it's just on tasks run via ? It works when running Core - Build explicitly but not ctrl+shift+b: !
should work for dependsOn tasks
works w ctrl+shift+b for other default build tasks () https://user-
works w ctrl+shift+b and the VS Code build task for me https://user-
can you pls send me the exact task config this isn't working for?
it's was just what was shown in the screenshot, the small change to . Might be related to Windows somehow then if you don't see it?
not sure why I can't reproduce it, but could be fixed by
I can still repro this in the latest insiders.
yes so can on Windows. we're going to debug
are there any task load messages in the output channel?
or any way the build task on windows is handled specially?
If there's an issue reading tasks from then an error should be logged to the tasks output channel, and I don't have any. The Run Build Task command shouldn't be handled any differently here, and I confirmed that this isn't build specific by making this keybinding:
to verify: set an icon for a dependency task
If I just set the icon color it now changes the icon away from the tools icon (its still the tools icon in the task quick pick): !
Change:
resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.8.0.tgz#4bc6bb4dbfea5b0d2d7978d6c5cef922d584fb4f" integrity sha512-dlpYPsv0C9S6v6+T/h/d/otSbdUTizMJdxvSoS34tUpMOHev6iW7Zqt5KRFqYxl4vCqpDk9Wmhb3fKL3kwX5fQ== <del> xterm@4.9.0-beta.8: version "4.9.0-beta.8" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.9.0-beta.8.tgz#ca121934d63f88668d2d5b11d9b2fc3bde7bd805" integrity sha512-EEonYBLANDUBfEeEnHG632bZdgBaAUWst8LFr6oC6f2uLFfJGHQvVJuLaEkPtRvS+jOeoorEXZRPmso1/ANHXA== </del> <ins> xterm@4.9.0-beta.24: version "4.9.0-beta.24" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.9.0-beta.24.tgz#48f0990c6d32ad3a9bcc4fb49531d7effdaccea5" integrity sha512-CIVxxxbBiSw1WOMkIjjivaiIC9jNgih4klfWsRGx0qiDF5nbzHuLXkPTt+yAQUu9FCyTUwECm9Pkl3gUsSaGKg== </ins> y18n@^3.2.1: version "3.2.1"

Discussion:
Since we don't know when links are no longer cached by , we cannot drop the objects. Upstream part:
Change:
if (!this._updateCustomBuiltinExtensionsCachePromise) { this._updateCustomBuiltinExtensionsCachePromise = (async () => { this.logService.info('Updating additional builtin extensions cache'); <del> const cached = await this.getCustomBuiltinExtensionsFromCache(); </del> const webExtensions: IWebExtension[] = []; const { extensions } = await this.readCustomBuiltinExtensionsInfoFromEnv(); if (extensions.length) {

Discussion:
Version : 1.76.1 Commit : Date : 2023-03-08T16:32:15.546Z Navigateur : Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/102.0.4985.0 Safari/537.36 Edg/102.0.1235.1 with the extension installed (stable) switch the display language to French, reload VS Code switch the display language to English, reload VS Code open the remote menu, see that there's still a French menu entry in there ! Open the extension view ! I also see it the other way around: !
Ahhh so it looks like this is returning remote-repositories extension: with the old german manifest. What’s odd to me is that remote-repositories is being returned by and ... but even still, I don't know much about this code, but I would expect that the cache would cache the manifest in its raw form with the placeholders and then allow the runtime to translate the manifest (which could be optimized to cache both raw and translated form and only re-compute when language changes)
I'm giving this one to you since it seems like a issue from the caching changes.
It seems we are translating the manifest always even if it is cached. But, I observed that some how (I do not know, may be in the old code), cache is having the already translated manifest. Therefore, while translating nothing gets translated. We do update cache every time but it seems if the version has not changed, we reuse the entry from the cache. There is no reason we have to reuse the entry from the cache. So fixed it by recomputing the cache entry always while updating the cache.
Change:
: json.faculty ? 'faculty' : 'none'; <ins> } else { edu = 'unknown'; </ins> } } catch (e) { <del> // No-op } let managed: string | undefined; try { const user = await this.getUserInfo(token); // Apparently, this is how you tell if a user is an EMU... managed = user.accountName.includes('_') ? 'true' : 'false'; } catch (e) { // No-op } if (edu === undefined && managed === undefined) { return; </del> <ins> edu = 'unknown'; </ins> } /* __GDPR__

Discussion:
<!-- 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/No <!-- 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: NA OS Version: NA Steps to Reproduce: The github education team sees about calls from Visual-studio-code in an hour for api/user. This is quite unusual and since we are rate limiting anyway, it is not an immediate issue. From initial discussions with I understand that the call is made only for telemetry and has no impact on the user. So, raising this bug, if we can find a better way to do telemetry without having to rate limit. This here shows some more details.
, can you please help me understand what is the likelihood of this work getting prioritised and by when can we expect to resolve this issue.
I wasn't able to get to it this week during our allocated debt time so I will try again to make time early April. I'll let you know if anything changes.
Change:
"version": "2.0.0", "tasks": [ { <del> "label": "npm watch", "command": "npm", "args": ["run", "watch"], </del> <ins> "label": "yarn watch", "command": "yarn", "args": ["watch"], </ins> "type": "shell", "presentation": { "reveal": "silent",

Discussion:
Issue Type: <bBug</bClone VS Code repo Follow the instructions for linking vscode-html-language-service will fail, as the project/extension has since moved to yarn. works fine. VS Code version: Code 1.62.0 (, 2021-11-03T15:23:01.379Z) OS version: Windows_NT x64 10.0. Restricted Mode: No Remote OS version: Linux x64 4.19.128-microsoft-standard <!-- generated by issue reporter --