jiebi/CodeConvo huggingface dataset:
Change:
super(); this._expanded = typeof options.expanded === 'undefined' ? true : !!options.expanded; this._orientation = typeof options.orientation === 'undefined' ? Orientation.VERTICAL : options.orientation; <del> this.ariaHeaderLabel = localize('viewSection', "{0} Section", options.title); </del> <ins> this._ariaHeaderLabel = localize('viewSection', "{0} Section", options.title); </ins> this._minimumBodySize = typeof options.minimumBodySize === 'number' ? options.minimumBodySize : this._orientation === Orientation.HORIZONTAL ? 200 : 120; this._maximumBodySize = typeof options.maximumBodySize === 'number' ? options.maximumBodySize : Number.POSITIVE_INFINITY;

Discussion:
GitHub Tags:#A11yMAS;#A11yTCS;#A11ySev2;#DesktopApp;#Win32;#Visual Studio Code Client;#BM-VisualStudioCodeClient-Win32-Aug2022;#WCAG1.3.1;#NVDA; #ScreenReader;#JAWS;#AILimited;#Element:Button; Application Name: Visual Studio Live Share Application version: 1.56.2 (user setup) Windows Version: Win10 VS Code a project (e.g., vsls-guestbook) in VSCode. till “sign in” button. till "Live share" under Extensions and hit enter on the NVDA and tab to drop down 'Visual Studio live share work' screen. The label of the 'Visual Studio live share work….' is being read as 'folder section button' when the screen reader focus moves to it using tab key. Similar issue is observed with JAWS. The screen reader should read it as 'Visual Studio live share work button' when screen reader focus moves to it. People who uses screen reader may face difficulty while activating an object when the accessible label is different than that of the visible labels. https://user-
logged for primary bug
I think this issue makes sense. In short - aria label of the explorer view should contain the name of the top folder. Currently it is just "Folders". So it should be dynamic. Assigning to
Actually not too sure how to fix this one. The section being read out is the static section name of the view pane We do have an aria label within that section header with the name of the folder which dynamically updates but that never gets focused. The pane registration is static and we don't know the folder name at that time
there's the  method in the . Update header should set the aria label of the header. And the explorer should call updateHeader every time the content of the header changes (which it might do already).

could you please the bug in open state the bug can be closed only by trusted tester after verification right now the fix is not present in the app Version: 1.72.0-insider (user setup) Commit: Date: 2022-09-23T05:17:37.024Z Electron: 19.0.17 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes !
please look at the label that the VS Code bot has to the issue. It says "unreleased". Once the bot adds the label "released" that means the fix is present. We can not leave the issue open for the tester to close this since this does not align with the rest of our VS Code processes. In case the bug is not fixed after it is released, just comment on the issue and we will reopen it. Thanks!
GitHubTags:#Closed;
Change:
order: 1.1 }, { id: MenuId.MenubarGoMenu, <ins> precondition: null, </ins> group: '4_symbol_nav', order: 2, }]

Discussion:
Type: <bBug</b- VS Code Version: 1.74.1 OS Version: Windows NT x64 10.0. Issue appeared just after upgrading VSCode to ver. 1.74.1 Currently, it is impossible to go to the function definition by clicking Ctrl+Click on the function name or using the F12 button. Also, the Go to definition option in Top Menu-Go-Go to Definition is disabled. VS Code version: Code 1.74.1 (, 2022-12-14T10:30:51.966Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
What code language? Is the option also disabled in the context menu? was a previous issue about this and related options not getting enabled in the top-level Go menu. Maybe this has come back. Do you think this didn't happen in 1.74.0?
- maybe caused by
Yeah, looks like the precondition for the command is too strong
Javascript I don't have such an option in the context menu I'm not 100% sure, which version I had previously installed, but I'm using VSCode almost every day, so I'm pretty sure I was using 1.74.0 or 1.73.1, and that behavior has occurred after auto-upgrade to 1.74.1. I've never noticed anything like it before.
After a clean uninstall (Uninstalled and deleted %APPDATA%Code and %USERPROFILE%.vscode), and installing 1.74.1 again, the problem does not occur anymore.
Change:
} private registerKeybindingEditorActions(): void { <ins> const that = this; </ins> KeybindingsRegistry.registerCommandAndKeybindingRule({ id: KEYBINDINGS_EDITOR_COMMAND_DEFINE, weight: KeybindingWeight.WorkbenchContrib,

Discussion:
With there is a new -menu which a big blue buttons. This is used in the merge editor and to hint to open the merge editor. This new menu should be used for: [x] [ ] ~~ / [x] [ ]
Other potential adoptors [ ] [ ] [ ] [ ]
Digging into it, I don't think can be adopted for the diff editor, as the button should be for both editors, not only the right side ( is a , but is ).
Change:
resolved "https://registry.yarnpkg.com/typescript/-/typescript-2.6.2.tgz#3c5b6fd7f6de0914269027f03c0946758f7673a4" integrity sha1-PFtv1/beCRQmkCfwPAlGdY92c6Q= <ins> typescript@^4.1.2: version "4.1.2" resolved "https://registry.yarnpkg.com/typescript/-/typescript-4.1.2.tgz#6369ef22516fe5e10304aae5a5c4862db55380e9" integrity sha512-thGloWsGH3SOxv1SoY7QojKi0tc+8FnOmiarEGMbd/lar7QOEd3hvlx3Fp5y6FlDUGl9L+pd4n2e+oToGMmhRQ== </ins> uc.micro@^1.0.1, uc.micro@^1.0.3: version "1.0.3" resolved "https://registry.yarnpkg.com/uc.micro/-/uc.micro-1.0.3.tgz#7ed50d5e0f9a9fb0a573379259f2a77458d50192"

Discussion:
Steps to Reproduce: that 52 of 69 issues are unrelated to security
btw I am seeing 84 errors, many of those are errors for async-import-statements. I am also surprised that complains about the use of trusted types policies. What are we supposed to do with such errors?
84 errors ? After I only see 19 and related issues. The issues are a current limitation of tsec which does not yet understand the Worker construction (we will fix it in tsec and send you and update when it is done, likely sometime next quarter). As for the errors, these are "expected" as they indicate the "vulnerable surface" of your code that requires manual review. In google, usages of are only allowed for the security team, which we use to exposes secure by construction APIs. That being said this does not necessarily translate well to your case, and I will invest some time in the first half of 2021 to: reduce / restrict and review current usages of improve devX around non-TrustedTypes supported browsers The good news is that apart from , it seems that all of your code is Trusted Types compatible & you should be able to start experimenting with enforcing Trusted Types through the header. For reference, here are all the errors I see:
Yeah, the is something new and an oversight. There is also still this then we should we good. I have running locally with trusted types enforced and default policy that logs and haven't found more places
Yeah, after that. I have a feeling that yarn handle these packages well.
Change:
], "folding": { "markers": { <del> "start": "^=pods*$", "end": "^=cuts*$" </del> <ins> "start": "^(?:(?:=pods*$)|(?:s*#regionb))", "end": "^(?:(?:=cuts*$)|(?:s*#endregionb))" </ins> } } }  No newline at end of file

Discussion:
VS Code has support for . It would be nice to also have support for "normal" region folding.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.732 --- <!-- score: 0.506 --- <!-- score: 0.503 --- <!-- score: 0.456 --<!-- potentialduplicatescomment --
Change:
separator: { label: separator } }); } <ins> isCustomTitleFormat(): boolean { const title = this.configurationService.inspect<string>(WindowSettingNames.title); const titleSeparator = this.configurationService.inspect<string>(WindowSettingNames.titleSeparator); return title.value !== title.defaultValue || titleSeparator.value !== titleSeparator.defaultValue; } </ins> }

Discussion:
Testing I think we will soon turn command center on by default. What is the impact on then? I see we are only showing the full title in the hover now, but I wonder if we need another setting (?) so that users still can configure what we show in the command center? ! Or maybe we should find a way to show the even in the command center with ellipsis if overflowing. //cc
Seems reasonable to me
Enabling the command centre removes my custom window title, showing the full path of the currently focussed editor. I find this very useful especially when there are files with the same name but in different directories. Can't the command centre show the full custom window title (without having to hover over it)? Without this, I would permanently disable it.
We can say the default is different but a customisation is honoured
To verify enable command center configure and/or validate that any customization is picked up by the CC reset above settings validate that the CC uses a default
Any reason we wouldn't also apply this with the default setting? My worry is that when we eventually make command center on by default, the setting would basically not work until you change it? I think it looks good when enabled even with default setting: !
The idea is that the CC shows an affordance to do something, like "Search vscode" - we replaced "search" with the icon which watered this down a bit. The worry is that the more title-stuff we put here the less likely it is that folks understand this as affordance
Change:
// Windows 32-bit warning if (isWindows && this.environmentService.os.arch === 'ia32') { const message = localize('windows32eolmessage', "You are running {0} 32-bit, which will soon stop receiving updates on Windows. Consider upgrading to the 64-bit build.", this.productService.nameLong); <del> const actions = [{ label: localize('windowseolBannerLearnMore', "Learn More"), href: 'https://aka.ms/vscode-faq-old-windows' }]; this.bannerService.show({ id: 'windows32eol.banner', message, ariaLabel: localize('windowseolarialabel', "{0}. Use navigation keys to access banner actions.", message), actions, icon: Codicon.warning }); </del> this.notificationService.prompt( Severity.Warning,

Discussion:
I keep pressing the X on this message and it still keeps coming back. Every single time I open a window. I have told it to go away almost 50 times now. I am being driven towards insanity. <img width="826" alt="image" src=""May this bug report stand in evidence that I have gotten the message. Thank you. Version: 1.83.0 (Universal) Commit: Date: 2023-10-03T16:13:15.449Z (3 days ago) Electron: 25.8.4 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: Darwin x64 18.7.0
Will just remove the banner.
should we mark this as author verification required? I'm assuming those testing internally would have updated their MacOS
how do I remove the banner in windows 8?
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
is the issue fixed for you on the latest ?
Feel free to mark as verified via code review.
Change:
const extensionPacks: ExtensionSuggestion[] = [ { name: localize('welcomePage.javaScript', "JavaScript"), id: 'dbaeumer.vscode-eslint' }, <del> { name: localize('welcomePage.typeScript', "TypeScript"), id: 'ms-vscode.vscode-typescript-tslint-plugin' }, </del> { name: localize('welcomePage.python', "Python"), id: 'ms-python.python' }, // { name: localize('welcomePage.go', "Go"), id: 'lukehoban.go' }, { name: localize('welcomePage.php', "PHP"), id: 'felixfbecker.php-pack' },

Discussion:
First, thanks for making VSCode soooo awesome! Wouldn't be as productive as I am without it Currently, VSCode suggests installing the to have support for TypeScript. However, is supposedly going to be deprecated sometime this year. ! Change the suggested extension to ESLint instead. This way, we're providing a solution to the community that is future-proof (at least for the foreseeable future) I'd be happy to open a PR if you were to accept this proposed solution. (it looks like this would be a matter of replacing the extension id here: )
Removing it sounds good. We already stopped recommending tslint for general ts users: Probably just remove the whole typescript section for now. Setting up eslint for TypeScript is not simple enough at the moment to show on the welcome page in my opinion Can you submit a PR that does that?
Agree with you there. Definitely!
I noticed you the "help wanted". I'm planning to submit a PR. Can we change the label indicate this issue is in progress or taken?
Change:
} // not at end <del> if (index < parts.length - 1) { </del> <ins> if (iterator.hasNext()) { </ins> if (child instanceof BranchNode) { <del> const result = this._delete(child, parts, index + 1); </del> <ins> const result = this._delete(child, iterator.next()); </ins> if (typeof result !== 'undefined' && child.size === 0) { node.delete(name);

Discussion:
Related to a folder with in name a file to it it ! It will duplicate itself: !
Forgot to update the method in :man_facepalming:
Verification: Follow steps in first comment.
Change:
import { IContextKeyService, IContextKey } from 'vs/platform/contextkey/common/contextkey'; import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; import { IStorageService, StorageScope } from 'vs/platform/storage/common/storage'; <del> import { IThemeService, registerThemingParticipant } from 'vs/platform/theme/common/themeService'; </del> <ins> import { IThemeService } from 'vs/platform/theme/common/themeService'; </ins> import { ICodeEditor, isCodeEditor } from 'vs/editor/browser/editorBrowser'; import { memoize } from 'vs/base/common/decorators'; import { dispose, IDisposable, Disposable } from 'vs/base/common/lifecycle';

Discussion:
I stumbled over and saw that there are still many colors hard-coded. Also while at the .css file, it's good practice to qualify all rules with (or ) now that the workbench can be embedded in the web.
Thanks for great feedback. There was some unused CSS, like the .annotation in the repl, so I removed that. I have also now qualifed all with . There is still one hard coded color for in repl, but I believe tackled this with his great PR. Though I might be mistaken?
I did, indeed, add colour contribution points to the REPL as part of but eventually you asked me to defer those until later, I do not remember the reason precisely... So the REPL is still not theme-able, unfortunately.
thanks for refreshing my memory. In case you would like to contribute that part of your PR we are open to accept it now :D From the I only see a need for color, not sure if there is more.
I am working on this now. I am taking it a step further, though, and adding theming to most of the REPL elements (errors, warnings, infos, source filenames etc.). Basically I want the whole REPL view to be fully customisable.
To verify, make sure you can customise the following colors in the debug console. You can use the setting :
Change:
"name": "comment" }, { <del> "match": "^S.*:$", "name": "string path.searchResult" </del> <ins> "match": "^(?!s)(.*?)([^/n]*)(:)$", "name": "string path.searchResult", "captures": { "1": { "name": "dirname.path.searchResult" }, "2": { "name": "basename.path.searchResult" }, "3": { "name": "endingColon.path.searchResult" } } </ins> }, { <del> "match": "^  d+", "name": "constant.numeric lineNumber.searchResult" </del> <ins> "match": "^  (d+)(:| )", "captures": { "1": { "name": "constant.numeric lineNumber.searchResult resultPrefix.searchResult" }, "2:": { "name": "resultPrefixSeparator.searchResult resultPrefix.searchResult" } } </ins> } ] }

Discussion:
Not the gutter. The ones that are rendered in the editor area. (And whitespace x2 + colon).
The "click to go to line" functionality reads from those line numbers, and I don't know a way to get around that (Sublime for instance does the same). Closing as this would require a major implementation change with non-major benefit.
Line number already has a grammar scope . Could you add another scope for the colon after it, so it would be possible to make them both transparent from ?
sure, that's a good idea.
So far adding a scope for the "line number + colon" construct (), and subdividing the path scope into and (and also ). !
Updated the scope names. Example: !
Change:
} } <ins> async function tryRevealLineInNotebook(tocProvider: MdTableOfContentsProvider, editor: vscode.NotebookEditor, fragment: string): Promise<boolean> { const toc = await tocProvider.createForNotebook(editor.notebook); const entry = toc.lookup(fragment); if (!entry) { return false; } const cell = editor.notebook.getCells().find(cell => cell.document.uri.toString() === entry.sectionLocation.uri.toString()); if (!cell) { return false; } const range = new vscode.NotebookRange(cell.index, cell.index); editor.selection = range; editor.revealRange(range); return true; } </ins> async function tryRevealLineUsingTocFragment(tocProvider: MdTableOfContentsProvider, editor: vscode.TextEditor, fragment: string): Promise<boolean> { const toc = await tocProvider.getForDocument(editor.document); const entry = toc.lookup(fragment);

Discussion:
Repro a notebook with the following markdown cells: still in edit mode, Try clicking on Bug Nothing happens Clicking on works since the header is within the same cell
Change:
else if (/^vs/code/.test(sourceFile)) { return { name: 'vs/code', project: workbenchProject }; } <ins> else if (/^vs/server/.test(sourceFile)) { return { name: 'vs/server', project: serverProject }; } </ins> else if (/^vs/workbench/contrib/.test(sourceFile)) { resource = sourceFile.split('/', 4).join('/'); return { name: resource, project: workbenchProject };

Discussion:
Testing in Firefox, with Spanish (es-es) set Open "Get Started with VS Code in the Web" walkthrough Select last step (open up your code), then first command ("Open Folder" in English, "Abrir carpeta" in Spanish) Modal is in English: ! It isn't a new string, and I didn't think getting started or this command would be from an extension, but perhaps that is the case.
I also see this on modals on the overall welcome page when I try opening a file or folder: !
Thank you for your feedback. We are currently reviewing it (reference ).
This is an odd one. The string looks good here: but the file that that comes from doesn't show up at all in our Spanish files: I'll have to dig into why this is... any ideas?
might be a bug in the tool so that the localize call is not detected. When you generate the export is the string included.
Ok the web strings are now bundled in language packs. It may take a minute for all these new strings to make their way through the translation system... but by end game it should be good.
Change:
@ITerminalService terminalService: ITerminalService, @ITerminalEditorService terminalEditorService: ITerminalEditorService, @ITerminalGroupService terminalGroupService: ITerminalGroupService, <del> @IConfigurationService configurationService: IConfigurationService, @IContextKeyService contextKeyService: IContextKeyService </del> <ins> @IConfigurationService configurationService: IConfigurationService </ins> ) { super();

Discussion:
Testing into the editor. status bar still says "Tab Moves Focus". I think I'd only expect it to say that when I'm focused in the terminal.
If you toggled it to on in the editor before focusing the terminal, then this is expected. We remember the toggled state for each context until the window is reloaded and it gets reset to the configured value I realize that's kind of confusing and was not how I initially implemented this
I never toggled it at all, this was just using the settings.

Testing an editor and write something in it. tab until you reach the terminal. Type something in the terminal. . Realize that tab is correctly not moving focus in the terminal. command "Toggle Tab Key Moves Focus" out of the terminal and keep tabbing until you get back to your editor. something in the editor. again until you reach the terminal. something in the terminal. to tab out of the terminal. It looks like tab moves focus as toggled itself off. Tab moves focus seems to be off for both terminal and editor at this point until reload.
I can also cause similar behavior if I flip the settings.
what is supposed to happen now? What I think I expect to happen (and isn't happening): If I run "Toggle tab key moves focus" while in a place where it doesn't move focus via setting, then it now globally moves focus. If I run "Toggle tab key moves focus" while in a place where it does move focus, then it now globally does not move focus. However, I'm not a "tab moves focus" user, so maybe my expectations are bogus.
Thank you for testing. Those expectations are correct, except that the toggling does not apply globally - it is per area. So, if I have in settings: terminal tab focus mode: on editor tab focus mode: off where: = status bar indicator = no status bar indicator focus the terminal focus the editor focus the terminal and toggle it off focus the editor and toggle it on focus the terminal focus the editor reload the window and focus the terminal focus the editor I see that this is not working atm because I'm not reacting to configuration changes
fyi for easier testing since the command palette can cause the terminal to no longer be focused, I'd suggest using the keybinding to toggle tab focus mode
Change:
} private async autoStoreEditSession() { <del> if (this.configurationService.getValue('workbench.experimental.editSessions.autoStore') === 'onShutdown') { </del> <ins> if (this.configurationService.getValue('workbench.experimental.cloudChanges.autoStore') === 'onShutdown') { </ins> const cancellationTokenSource = new CancellationTokenSource(); await this.progressService.withProgress({ location: ProgressLocation.Window,

Discussion:
extension suppresses cancellation errors so Create New Codespace errors or cancellations show up as reports all errors as rather than distinguishing cancellation errors
Change:
cols: number, rows: number, userHome: string | undefined, <del> isScreenReaderModeEnabled: boolean </del> <ins> isScreenReaderModeEnabled: boolean, variableResolver: terminalEnvironment.VariableResolver | undefined </ins> ): Promise<ITerminalChildProcess> { await this._terminalProfileResolverService.resolveShellLaunchConfig(shellLaunchConfig, { remoteAuthority: undefined,

Discussion:
With we are trying to remove from the configuration resolver service. The new way to get the environment is async and requires that the all the configuration resolver methods be async. I have started the adoption of the new async methods in , but there's one use in terminal that looks like it will require more work: Option 1: Convert that use of to use . Option 2: I provide a new method on the configuration resolver service that is sync, but requires you to pass in your own . Which option makes the most sense here?
I think the usage of in must remain sync since it's used as part of the extension API. Is this a problem there since is fine to use? The main purpose of this type was to share code between variable processes.
Sounds like Option 2 is the way to go then. I will add a new method that is sync and lets you pass in your own .
Added: will that let you keep your code reuse?