jiebi/CodeConvo huggingface dataset:
Change:
resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.12.0-beta.36.tgz#460f80829a78c979a448d5b764699af3f0366ff1" integrity sha512-sgX7OHSGZQZE5b4xtPqd/5NEcll0Z+00tnTVxKZlXf5XEENcG0tnBF4I4f+k9K3cmjE1UIUVG2yYPrqWlYCdpA== <del> xterm-headless@4.19.0-beta.55: version "4.19.0-beta.55" resolved "https://registry.yarnpkg.com/xterm-headless/-/xterm-headless-4.19.0-beta.55.tgz#0f8fafefef57cd033100f4ffa60a04e71ed5e122" integrity sha512-LR2LyKLF/eo/m52qIlONnxNYr7a/Vp6X0M3CnaCFmYKXhjEMHqEOJOAUz/hhKG/R9j7apLgaNj/uw0mCdL780g== xterm@4.19.0-beta.55: version "4.19.0-beta.55" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.55.tgz#b2b4acca6ef5c7a4761098b5e1629b7f93deefc9" integrity sha512-AGT7b6UYZ0o7jtyLZ8KwY8Rchdqv3Pi6Nkcs4YbxR0opbQjIovEc44jkGmudfVYcGaFWsA/bdxM6feJ7VXRAlg== </del> <ins> xterm-headless@4.19.0-beta.56: version "4.19.0-beta.56" resolved "https://registry.yarnpkg.com/xterm-headless/-/xterm-headless-4.19.0-beta.56.tgz#7e6bdc8d647916bf5de64a73eee6bd508d25e344" integrity sha512-EZoR/HqZoernhFngFQp7gUPy+G0TpEJkbJ9HVZcINC3m8wuV1wZKfZ4xBhsRPfhSJ7rsPnqbC+qez5ZjxwYEIw== xterm@4.19.0-beta.56: version "4.19.0-beta.56" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.56.tgz#a3f1021b43ac04aa0c3f7b06f1b44ad34d487879" integrity sha512-kywKIK61oPjbloZI+jXY1zgjQm/ghOsFFMjb79IIMaWocUDDqdpo9MmGwziTVZYu4w/Air2Zfas9UWBu4/KEyA== </ins> yallist@^4.0.0: version "4.0.0"

Discussion:
Testing Have the same content in the editor and in the terminal. Search for something. Notice how the occurrence are fat and visible in the editor scrollbar. Notice how they are not fat and sparse in terminal. They seem to be incorrectly placed since my match is almost on every line and that is not the feeling I get from the terminal scroll bar ! !
How many lines do you have in the editor for this example? It looks like there are a bunch of empty lines near the bottom? The way we calculate the position of terminal scroll bar decorations is line / number of lines in the buffer.
I had the same number of lines as the terminal which is 23. If I had more lines in the editor I think that would mean that the decorations are smaller in the editor, not larger and that seems to be happening :)
to me, it looks like the decorations are closer together and not taking up as much vertical space in the scrollbar see how the lower half is just empty? !
Good point. Now I have disabled scrolling beyond last line in the editor. And they render the equal height. But look at the decorations - they are very different. Do you also see this on your machine? !
The ones in the editor are double the height - likely because of device pixel ratio on a mac that's getting taken into account there and probably should be also for the terminal. ! !
Strange because we are doing the right thing here, but is 1 here for me on a mac . !
We can make these heights different based on the number of lines in the buffer similar to what the editor does
Upstream issue:
Change:
const handleClickOrTouch = (e: MouseEvent | GestureEvent, preserveFocus: boolean): void => { tab.blur(); // prevent flicker of focus outline on tab until editor got focus <del> if (e instanceof MouseEvent && e.button !== 0) { </del> <ins> if (e instanceof MouseEvent && (e.button !== 0 /* middle/right mouse button */ || (isMacintosh && e.ctrlKey /* macOS context menu */))) { </ins> if (e.button === 1) { e.preventDefault(); // required to prevent auto-scrolling (https://github.com/microsoft/vscode/issues/16690) } <del> return undefined; // only for left mouse click </del> <ins> return undefined; </ins> } if (this.originatesFromTabActionBar(e)) {

Discussion:
open vscode for web on macOS ctrl+click into a tab that is not active context menu opens but also the tab opens fyi this is similar to and requires the same fix. Interestingly on Electron this does not seem to be an issue, maybe produces context menu event in Electron but not in Web?
Change:
} for (const item of completions.items) { <del> const range = item.range ? Range.lift(item.range) : defaultReplaceRange; </del> <ins> let range = item.range ? Range.lift(item.range) : defaultReplaceRange; </ins> if (range.startLineNumber !== range.endLineNumber) { // Ignore invalid ranges.

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.69 OS Version: Windows_NT x64 10.0. Steps to Reproduce: When the completion contains incomplete bracketPairs, the VS Code API corrects them, but the range is not updated so the tabbing behavior doesn't work as expected. Additionally, the grey text shown is also not shown accurately. Example 1: The code context is React.useEffect(() ={ fetch("/api") .then((res) ()) }) ! In this GIF, the insertText provided is . When the completion is accepted using Tab, the don't get accepted. If the code on the line is , the insertText is and the cursor is marked by , then the completion shows up as ! Example 2: A simpler case is when code on the line is , the completion shown is . When the user hits Tab to accept, their cursor is taken between . If the insertText is at this point, it will be closed by the API. But the range is not updated to match the already existing and so it shows up as grey text. ! cc
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.69.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Thanks for the issue and the PR! I'll get it in in the next release, as we already have feature-freeze and focus on fixing bugs in new features.

hmm should this be assigned to the July milestone since i see it is merged to main? And thus it will be part of the upcoming stable release in 10 days? Thanks
https://user-
The autocomplete text no longer has the parentheses, but the description does. Is it expected that they don't get completed ?
You have to try this with the intellicode extension. I suggest to get this validated by
Were you able to repro the bug you found with the Intellicode-Completions extension installed? I cannot repro it on my end.
Change:
...this.state, HEAD: this.repository.HEAD, isMergeInProgress: this.repository.mergeGroup.resourceStates.length !== 0, <ins> isRebaseInProgress: !!this.repository.rebaseCommit, </ins> repositoryHasChangesToCommit: this.repositoryHasChangesToCommit() }; }

Discussion:
Testing [ ] Update label accordingly (deferred) [x] Remove secondary actions
Pushing this out to the next milestone as there are some things I need to investigate first related to the rebase flow.
Decided to keep the "Commit" label for the button to keep things simple. Will change it if needed, based on customer feedback.
Change:
const postCommitCommand = config.get<'none' | 'push' | 'sync'>('postCommitCommand'); if ((opts.postCommitCommand === undefined && postCommitCommand === 'push') || opts.postCommitCommand === 'push') { <del> await this._push(repository, { pushType: PushType.Push, silent: true }); </del> <ins> await this._push(repository, { pushType: PushType.Push }); </ins> } if ((opts.postCommitCommand === undefined && postCommitCommand === 'sync') || opts.postCommitCommand === 'sync') { await this.sync(repository);

Discussion:
Testing Commit & Push does not publish unpublished branch. I would expect this to happen. Currently, when on an unpublished branch, Commit & Push behaves as Commit.
This seems to be a problem with both the "Commit & Push" action button as well as the post commit command setting. "Commit & Sync" does work as expected, as well as invoking the "Git Push" command from the "Source Control" viewlet also works.
I'm unable to verify this issue right now because clicking on the chevron doesn't work. Opened an issue at
Chevron seemed to work for me so I'm marking verified.
Change:
} if (this.servers.length > 1) { if (isLanguagePackExtension(extension.manifest)) { <del> return this.uninstallEverywhere(extension); </del> <ins> return this.uninstallEverywhere(extension, options); </ins> } return this.uninstallInServer(extension, server, options); } <del> return server.extensionManagementService.uninstall(extension); </del> <ins> return server.extensionManagementService.uninstall(extension, options); </ins> } <del> private async uninstallEverywhere(extension: ILocalExtension): Promise<void> { </del> <ins> private async uninstallEverywhere(extension: ILocalExtension, options?: UninstallOptions): Promise<void> { </ins> const server = this.getServer(extension); if (!server) { return Promise.reject(`Invalid location ${extension.location.toString()}`); } <del> const promise = server.extensionManagementService.uninstall(extension); </del> <ins> const promise = server.extensionManagementService.uninstall(extension, options); </ins> const otherServers: IExtensionManagementServer[] = this.servers.filter(s => s !== server); if (otherServers.length) { for (const otherServer of otherServers) { const installed = await otherServer.extensionManagementService.getInstalled(); extension = installed.filter(i => !i.isBuiltin && areSameExtensions(i.identifier, extension.identifier))[0]; if (extension) { <del> await otherServer.extensionManagementService.uninstall(extension); </del> <ins> await otherServer.extensionManagementService.uninstall(extension, options); </ins> } } }

Discussion:
I have no repro steps and am on the default profile in web and desktop with settings sync enabled in both, but I have re-installed the GitHub Pull Requests and Issues extension three times today and am wondering if there is something happening in extensions land, settings sync, profiles, or something else. What is the best way to debug this further? Settings sync logs below:
Also it looks like I cannot install in web at all, if I click on Install Pre-release the install button says Installing and then goes back to Install Pre-release, but the extensions viewlet shows a progress indicator that never goes away
There is a bug already for it. I will look into it. Regarding an extension getting uninstalled, it would be great if you can share the settings sync log and shared process log from the machines.
I just hit this issue with profiles and settings sync enabled Desktop: Have two profiles (Default and Testing) Desktop: Install Github theme extension in both profiles Desktop: Enable Settings Sync and sync all Web () - Sync to get all profiles and extensions and be in Default profile Desktop: Go into Testing profile and uninstall Github theme extension and sync Web: Let the sync happen and in a moment Github theme extension gets uninstalled.
Change:
* @param providerId The id of the provider to use * @param scopes A list of scopes representing the permissions requested. These are dependent on the authentication provider * @param options The {@link AuthenticationGetSessionOptions} to use <del> * @returns A thenable that resolves to an authentication session </del> <ins> * @returns A thenable that resolves to an authentication session if available, or undefined if there are no sessions </ins> */ <del> export function getSession(providerId: string, scopes: readonly string[], options: AuthenticationGetSessionOptions & { forceNewSession: true | { detail: string } }): Thenable<AuthenticationSession>; </del> <ins> export function getSession(providerId: string, scopes: readonly string[], options?: AuthenticationGetSessionOptions): Thenable<AuthenticationSession | undefined>; </ins> /** * An {@link Event} which fires when the authentication sessions of an authentication provider have

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.63 OS Version: Windows 11 Steps to Reproduce: an extension which calls passing the newly finalized option TypeScript says the return type is potentially . Previously (prior to finalization) it said that the return type was I think the intent of the forceNewSession option is to ensure that getSession always returns an AuthenticationSession, but because forceNewSession has been to AuthenticationGetSessionOptions as part of api finalization, it now falls into this case rather than this case Is this something we can get fixed in the published types? I think if you switch their order, that would be enough (at least that seems to work locally). In the meantime I have worked around it by downloading the off the main branch, switching their order in that copy, and deleting the conflicting copy of from node_modules.
Candidate pushed via
Verification steps: In an extension, grab the from the release branch and replace the file with it. put this in your extension's code: The return type of that call should be NOT
Change:
return TPromise.wrapError<boolean>(err); }); <ins> if (isRoot(path)) { return TPromise.as(true); } </ins> return mkdir().then(null, (err: NodeJS.ErrnoException) => { if (err.code === 'ENOENT') { return mkdirp(dirname(path), mode).then(mkdir);

Discussion:
In version 0.10.1 it is no longer possible to write to the root of a drive (which worked up to 0.9.1). When trying to save to e.g. , the following error message appears: Tested on Windows 7 Ultimate and Windows 10 Professional, US language, German region settings.
are you sure you can save there, can you try with nodepad?
Yes, I can write a text file with notepad. And I also tried other drives. What I found out in the meantime is that this happens only when creating a new file. Opening, editing and saving an existing file works correctly.
so you do Ctrl+N, type something and then try to save it to r: from the windows save dialog?
Exactly. The error message appears trying to use Save, Save As or (when creating multiple files), Save All.
is R: some drive created with subst or a real physical drive? I assume it is not the root drive where windows is installed?
R: is a RAM disk - so I suspected this to be the problem at first. That's why I checked on other, "real" drives (except the system drive C:), and I can reproduce the behavior.
What I'm not sure about is why VSCode is trying to run at all. When I do this from a command line (), I get an "Access is denied" there as well - which doesn't surprise me.
It actually tries to create the root path :) If you run VS Code as non-admin, it won't even let you try to save to but if you run VS Code as admin, it will let you try but fails on creating . !
Thanks, will look into it!
This looks like a bad regression in (). It relies on the EEXIST error but when reaching the root drive, it ends in EPERM. I think you touched this function last.
As of now, 0.10.8-insider build run as an administrator lets you save to D:<filenameAs far as I can see, this is truly closed.
Change:
group?: string; } <ins> interface IInstanceCount { count: number; } </ins> interface IActiveTerminalData { terminal?: ITerminalInstance; task: Task; promise: Promise<ITaskSummary>; state?: TaskEventKind; <ins> count: IInstanceCount; </ins> } interface IReconnectionTaskData {

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:
const optionDisabled = (<ISelectOptionItem>element).optionDisabled; data.optionText.textContent = optionText; <del> data.root.setAttribute('aria-label', nls.localize('selectAriaOption', "{0}", optionText) + ',.'); </del> if (typeof element.optionDescriptionText === 'string') { const optionDescriptionId = (optionText.replace(/ /g, '_').toLowerCase() + '_description_' + data.root.id); <del> data.root.setAttribute('aria-describedby', optionDescriptionId); </del> <ins> data.optionText.setAttribute('aria-describedby', optionDescriptionId); </ins> data.optionDescriptionText.id = optionDescriptionId; <del> data.optionDescriptionText.setAttribute('aria-label', element.optionDescriptionText); </del> <ins> data.optionDescriptionText.innerText = element.optionDescriptionText; </ins> } <del> // Workaround for list labels data.root.setAttribute('aria-selected', 'true'); </del> // pseudo-select disabled option if (optionDisabled) { dom.addClass((<HTMLElement>data.root), 'option-disabled');

Discussion:
Voiceover does not read new option details because of describedby issue. May require the new ARIA combo box model.
Any problem with me creating new tags for NVDA and voiceover like there is already a tag for jaws? Accessibility-NVDA Accessibility-Voiceover I will also volunteer to do triage on accessibility issues if I can identify them.
Change:
const noMenubar = this.currentMenubarVisibility === 'hidden' || (!isWeb && isMacintosh); const noCommandCenter = !this.isCommandCenterVisible; <del> const noLayoutControls = !this.layoutControlEnabled; </del> <ins> const noToolBarActions = !this.layoutControlEnabled && !this.editorActionsEnabled && !this.activityActionsEnabled; </ins> <del> return zoomFactor < 1 || (noMenubar && noCommandCenter && noLayoutControls); </del> <ins> return zoomFactor < 1 || (noMenubar && noCommandCenter && noToolBarActions); </ins> } override layout(width: number, height: number): void {

Discussion:
See how layout controls are nice and large when zoomed in once: ! Now compare with editor actions. ! I think the issue is that some assumptions in the title bar are still being made based on layout controls showing or not but this should be more generalised to toolbar showing or not:
Change:
background-size: 16px; } <ins> .monaco-dropdown-with-default:hover { background-color: var(--vscode-toolbar-hoverBackground); } </ins> .monaco-dropdown-with-default > .dropdown-action-container > .monaco-dropdown > .dropdown-label .codicon[class*='codicon-'] { font-size: 12px; padding-left: 0px;

Discussion:
<img width="146" alt="CleanShot 2021-12-15 at 07 37 24 src="https://user-"<img width="146" src="https://user-"I think we originally talked about the split action having two hovers, like in the terminal, but not sure why that changed for the run button.
it's using the same widget afaik, the "shared hover" was meant to help indicate that they're linked.
No, they are not using the same widget because the run button's behavior was too different.
Change:
color: var(--vscode-descriptionForeground); } <ins> .monaco-list-row.selected .extension-list-item > .details > .description{ color: unset; } </ins> .hc-black .extension-list-item > .details > .description, .hc-light .extension-list-item > .details > .description { color: unset;

Discussion:
insiders, new user data dir choose Light+ theme extensions viewlet, click on an extension Notice color contrast is off. The text can not be readable when an extension has selection and focus fyi !
It seems description color was introduced by Hence assigning to him.
Yeah looks like the new color isn't getting overridden in a focused/selected state. Thought I fixed this but I'll take a look
Change:
} private async autoResumeEditSession() { <del> const shouldAutoResumeOnReload = this.configurationService.getValue('workbench.editSessions.autoResume') === 'onReload'; </del> <ins> const shouldAutoResumeOnReload = this.configurationService.getValue('workbench.cloudChanges.autoResume') === 'onReload'; </ins> if (this.environmentService.editSessionId !== undefined) { this.logService.info(`Resuming cloud changes, reason: found editSessionId ${this.environmentService.editSessionId} in environment service...`);

Discussion:
extension suppresses cancellation errors so Create New Codespace errors or cancellations show up as reports all errors as rather than distinguishing cancellation errors