jiebi/CodeConvo huggingface dataset:
Change:
}, 50); }); }); <ins> test('Code blocks should use leading language id (#157793)', async () => { const markdown = { value: '```js some other stuffn1 + 1;n```' }; const lang = await new Promise<string>(resolve => { renderMarkdown(markdown, { codeBlockRenderer: async (lang, value) => { resolve(lang); return simpleCodeBlockRenderer(lang, value); } }); }); assert.strictEqual(lang, 'js'); }); </ins> }); suite('ThemeIcons Support On', () => {

Discussion:
In the it says: It then gives : Although the spec does not mandate it, it would be nice if VS Code supported this format. Currently, adding more than just the language identifier after the backticks results in the code note rendering as code: ts const a = new MyClass(); ts foo const a = new MyClass(); <img width="473" alt="Screenshot 2022-08-10 at 15 32 18" src="https://user-"
This already is supported for Markdown highlighting and in markdown previews: ! Is this about support in too?
I don't know what's being used internally by the TS integration above, but I think it should work anywhere that VS Code is already handling these code blocks (my example above was hovers, but things like code completion documentation and other places that support code blocks should be the same - a lot of this content comes from external sources so there's benefit in VS Code being as compatible with what they may use as possible).
Change:
*--------------------------------------------------------------------------------------------*/ import 'vs/css!./media/processExplorer'; <ins> import 'vs/base/browser/ui/codicons/codiconStyles'; // make sure codicon css is loaded </ins> import { ElectronService, IElectronService } from 'vs/platform/electron/electron-sandbox/electron'; import { ipcRenderer } from 'vs/base/parts/sandbox/electron-sandbox/globals'; import { localize } from 'vs/nls';

Discussion:
Noticed how the process explorer is bundling and still. Can we not use Codicons for this? //cc
Oh this seems to be used in the issue reporter, not process explorer. But not sure how to actually see it...
are we actually using these icons? I'm not seeing it: !
it looks like these are only used when VSCode is connected to a remote to show the remote processes as well. I didn't even know we had that, pretty cool: ! Anyhow, my request still seems valid.
PR up at !
Change:
import { ExtHostConfigProvider } from 'vs/workbench/api/common/extHostConfiguration'; function spawnAsPromised(command: string, args: string[]): Promise<string> { return new Promise((resolve, reject) => { let stdout = '';

Discussion:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --WMIC is deprecated and has been for some time. Currently it is used for determining if any integrated terminal instances have any child processes. There are PowerShell commands that can return the count of child processes given a parent process ID, but I'm not sure what the performance hit for using PowerShell would be.
Windows doesn't maintain strong parent/child process relationships, so the design here needs some more thinking. If you're feeling gangster, you can call with and dig out the undocumented member. But I wouldn't bother, because you then need to consider and now points to something else entirely.
Thanks for all the help !
Change:
const picker = quickInputService.createQuickPick<ISnippetPick>(); picker.placeholder = nls.localize('pick.placeholder', "Select a snippet"); <del> picker.matchOnDescription = true; </del> <ins> picker.matchOnDetail = true; </ins> picker.ignoreFocusOut = false; picker.onDidTriggerItemButton(ctx => { const isEnabled = snippetService.isEnabled(ctx.item.snippet);

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. --Steps to Reproduce: trigger the Command Palette: command Try to search by a snippet's "Description" field for a word not in the prefix - does not work. The description field can be seen in the Command Palette but cannot be searched for successfully. Seems to be a regression, see Tested in Stable and Insiders. Version: 1.55.0-insider (user setup) Commit: Date: 2021-03-18T05:14:49.087Z Electron: 11.3.0 Chrome: 87.0.4280.141 12.18.3 V8: 8.7.220.31-electron.0 OS: Windows_NT x64 10.0. <!-- 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 direct to the extension publisher. The 'Help Report Issue' dialog can assist with this. --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.48 --<!-- potentialduplicatescomment --
I confirm this issue is happened on 1.54, while it worked on 1.43
Change:
return !value ? '' : value.toLocaleLowerCase(); } else if (this.shorthandName === 'capitalize') { return !value ? '' : (value[0].toLocaleUpperCase() + value.substr(1)); <ins> } else if (this.shorthandName === 'pascalcase') { return !value ? '' : this._toPascalCase(value); </ins> } else if (Boolean(value) && typeof this.ifValue === 'string') { return this.ifValue; } else if (!Boolean(value) && typeof this.elseValue === 'string') {

Discussion:
It would be nice to have additional snippet format options, e.g. kebabCase, camelCase, snakeCase, startCase, pascalCase. For example, for file named and snippet generated code would be .
Not sure yet as we would derive further from what is defined in TextMate
Why didn't you bring auto closing tag features in vs code for html
Code pointer:
FYI, I ended up using plugin.
I'm on it.
But ... but ... the issue had several formats: and PR only 1 (PascalCase)
Change:
when: WorkspaceHasCommenting }); <ins> const EXPAND_UNRESOLVED_COMMENT_COMMAND = 'workbench.action.expandUnresolvedComments'; CommandsRegistry.registerCommand({ id: EXPAND_UNRESOLVED_COMMENT_COMMAND, handler: (accessor) => { return getActiveController(accessor)?.expandUnresolved(); } }); MenuRegistry.appendMenuItem(MenuId.CommandPalette, { command: { id: EXPAND_UNRESOLVED_COMMENT_COMMAND, title: nls.localize('comments.expandUnresolved', "Expand Unresolved Comments"), category: 'Comments' }, when: WorkspaceHasCommenting }); </ins> KeybindingsRegistry.registerCommandAndKeybindingRule({ id: 'workbench.action.submitComment', weight: KeybindingWeight.EditorContrib,

Discussion:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Our users want to see which comments need to be worked on next. During a review round there might be some comments which are not actionable anymore as their threads got resolved. For better overview we think it is valuable to be able to expand only all unresolved (and therefore actionable) comments. Since we can't use anymore to do this from our extension. Reading there is no intention in bringing back this functionality. Introducing commands like (and probably also ) could be a way bring back some control over comment collapsed state to the extension without the need for extension to directly. cc
Tentatively adding for February.
The new command is "Comments: Expand Unresolved Comments".
To verify: Open a workspace with unresolved comments (a PR with comments using the GitHub Pull Requests and Issues extension works well for this). Collapse some comments in the editor. Run "Comments: Expand Unresolved Comments" and verify that all unresolved comments are expanded.
If a comment is already collapsed when I open the file, the command "Expand Unresolved Comments" doesn't work repro: an unresolved comment the current tab the tab again run the command - the comment is not expanded https://user-
good find! Will be fixed in the next insiders build.
Change:
callback: (error: ITerminalLaunchError | undefined) => void; } <del> export interface IDefaultShellAndArgsRequest { useAutomationShell: boolean; callback: (shell: string, args: string[] | string | undefined) => void; } </del> export const QUICK_LAUNCH_PROFILE_CHOICE = 'workbench.action.terminal.profile.choice'; export const enum TerminalCommandId {

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: latest commit on github OS Version: n/a Interfaces in and in are defined twice with exactly the same definition. It looks like the duplicate definitions were reverting an existing change:
Change:
collector.addRule(`.monaco-shell { color: ${windowForeground}; }`); } <ins> // Selection const windowSelectionBackground = theme.getColor(selectionBackground); if (windowSelectionBackground) { collector.addRule(`.monaco-shell ::selection { background-color: ${windowSelectionBackground}; }`); } </ins> // List highlight const listHighlightForegroundColor = theme.getColor(listHighlightForeground); if (listHighlightForegroundColor) {

Discussion:
All input box based widgets (find, file search, etc) need text selection foreground/background UI colors. Have to decide if there should be a global ::selection color or any individual ones are needed. !
Added via for May.
Change:
.monaco-workbench .panel.integrated-terminal .xterm:focus .xterm-viewport, .monaco-workbench .panel.integrated-terminal .xterm:hover .xterm-viewport { transition: opacity 100ms linear; <ins> cursor: default; </ins> } .monaco-workbench .panel.integrated-terminal .xterm .xterm-viewport::-webkit-scrollbar-thumb:hover {

Discussion:
VSCode Version: Code 1.17.0 (, 2017-10-04T23:44:50.318Z) OS Version: Windows_NT ia32 10.0. Extensions: <img width="387" alt="issue" src="https://user-"Steps to Reproduce: Bash Terminal on Scroll bar cursor is not highlight as pointer. <!-- Launch with to check. --Reproduces without extensions: Yes/No
Upstream issue:
Fixed in
Change:
KeybindingsRegistry.registerCommandAndKeybindingRule({ id: STEP_OVER_ID, weight: KeybindingWeight.WorkbenchContrib, <del> primary: isWeb ? (KeyMod.Alt | KeyCode.F10) : KeyCode.F10, // Browsers do not allow F10 to be binded so we have to bind an alternative </del> <ins> primary: KeyCode.F10, secondary: isWeb ? [(KeyMod.Alt | KeyCode.F10)] : undefined, // Keep Alt-F10 for web for backwards-compatibility </ins> when: CONTEXT_DEBUG_STATE.isEqualTo('stopped'), handler: async (accessor: ServicesAccessor, _: string, context: CallStackContext | unknown) => { const contextKeyService = accessor.get(IContextKeyService);

Discussion:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --We ran into this at Google: Currently, VSCode will use (like many debuggers) for stepping over on Electron, but on Web. The rationale, according to the code comment, is that browsers will not allow you to bind F10: I believe that is not fully correct: VSCode itself uses F10 (curiously exactly when in the browser), to focus the file menu: I changed the shortcut to F10 in the settings, and in my browser (Chrome on OS X) it worked fine - maybe it does not work on specific browsers? you removed for step over on web in - do you recall the exact reason? you the for application menu on web - why is this only on web? I would like to better understand if we can somehow make this work, as users generally expect to step over in debuggers, and having to type for step over, when e.g. step in is just is causing friction.
Besides the inconsistency between step in and step over shortcuts, and web and electron, another issue with is that this is "Toggle Maximization State" in Gnome:
I do not remember the exact reason. It seems like some browsers do not support this. Can you please try it out in Safari, Firefox, Edge and Chrome? And if it works across all browsers then maybe we can change this. Though I leave the decision up to who owns debug.
If I could confirm that it works on the four mentioned browsers, would you be open to changing this?
It works fine for me too in Edge on macOS. But yeah, if you could do a little testing in different browsers, and on Windows, I would set F10 by default. I suppose I have to keep alt+F10 as an alternate keybinding on web to not confuse people, hm
It's not explicitly stated where it in this issue , but I believe the only reason the menu focus F10 keybinding is web specific is because all other platforms had pre-existing methods that didn't work in web.
Sorry for the delay.

I have tested with Github Codespaces (because does not support debugging) on Windows: Edge Version 113.0.1774.50 (Official build) (64-bit) Chrome 113.0.5672.127 (Offizieller Build) (64-Bit) (cohort: Stable) Firefox 113.0.2 (64-Bit) Would that suffice to support stepping with F10 in addition to Alt-F10 on Web? Do you need me to send a PR or are you making the change yourself Rob?
Thanks for trying that. I would take a PR for it
Thanks!
Change:
comment: ['The task command line or label'] }, 'Executing task: {0}', commandLine), { excludeLeadingNewLine: true }) + taskShellIntegrationOutputSequence; } <ins> } else { shellLaunchConfig.initialText = taskShellIntegrationStartSequence + taskShellIntegrationOutputSequence; </ins> } } else { const commandExecutable = (task.command.runtime !== RuntimeType.CustomExecution) ? CommandString.value(command) : undefined;

Discussion:
!
works in OSS !
also works for me in insider's
works for that exact task for me !
It's because of this: Here's the I was using:
This works but it adds an extra line because of initialText so it doesn't look quite right: Before: ! After: !
Change:
append(moreInfo, $('.more-info-entry', undefined, $('div', undefined, localize('release date', "Released on")), <del> $('div', undefined, new Date(gallery.releaseDate).toLocaleString(undefined, { hourCycle: 'h23' })) </del> <ins> $('div', undefined, new Date(gallery.releaseDate).toLocaleString(locale, { hourCycle: 'h23' })) </ins> ), $('.more-info-entry', undefined, $('div', undefined, localize('last updated', "Last updated")), <del> $('div', undefined, new Date(gallery.lastUpdated).toLocaleString(undefined, { hourCycle: 'h23' })) </del> <ins> $('div', undefined, new Date(gallery.lastUpdated).toLocaleString(locale, { hourCycle: 'h23' })) </ins> ) ); }

Discussion:
The 'Last updated' and 'released on' dates on the extension page use the American format. This is confusing to many people. ! I tried to Spanish and German, but the problem remains: ! ! Consider using a unambiguous date format such as yyyy-mm-dd (ISO 8601)
I am not locating the datetime as a resource for localization, I'm assuming it is concatenated in runtime so not a loc issue. Please help if I'm mistaken.
I think using the unambiguous date format is a good way forward. However, we could do something where en-US is displayed one way everything else is displayed the other way... but I don't think that is 100% accurate.
is this issue closed? or still needs help?
Its still open and there is a PR which has to be reviewed.
Hello, is this issue still open? I am new to contributing to GitHub projects and this seems like a good first issue for me. Is there a way to claim this issue? If I am able to work on this, do you have any advice for me in contributing for the first time?
Thanks for your interest. This is already being worked on. Please look for another good first and help wanted issues. Thanks/
Change:
import { IUserDataProfileService } from 'vs/workbench/services/userDataProfile/common/userDataProfile'; import { isEqual } from 'vs/base/common/resources'; import { IUserDataProfilesService } from 'vs/platform/userDataProfile/common/userDataProfile'; <ins> import { IStringDictionary } from 'vs/base/common/collections'; </ins> export interface IPreferencesRenderer extends IDisposable { render(): void;

Discussion:
Add an unrecognized setting to See that it is correctly dimmed with no warning underline Add it to a language-specific settings block There is a warning, "This setting does not support per-language configuration which is misleading" !
Yeah, this feature is not supported for language specific settings.
To verify: Open and have following snippetMake sure first two settings and are shown dimmed with proper message.
<!-- 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!
Change:
const overrides = { resource: model.uri, overrideIdentifier: model.getModeId() }; const defaultFormatter = configService.getValue<string>(DefaultFormatter.configName, overrides); <ins> let autoFocusPick; </ins> const picks = formatters.map((provider, index) => { <del> return <IIndexedPick>{ </del> <ins> const isDefault = ExtensionIdentifier.equals(provider.extensionId, defaultFormatter); const pick = <IIndexedPick>{ </ins> index, label: provider.displayName || '', <del> description: ExtensionIdentifier.equals(provider.extensionId, defaultFormatter) ? nls.localize('def', "(default)") : undefined, </del> <ins> description: isDefault ? nls.localize('def', "(default)") : undefined, </ins> }; <ins> if (isDefault) { // autofocus default pick autoFocusPick = pick; } return pick; </ins> }); const configurePick: IQuickPickItem = { label: nls.localize('config', "Configure Default Formatter...") }; <del> const pick = await quickPickService.pick([...picks, { type: 'separator' }, configurePick], { placeHolder: nls.localize('format.placeHolder', "Select a formatter") }); </del> <ins> const pick = await quickPickService.pick([...picks, { type: 'separator' }, configurePick], { placeHolder: nls.localize('format.placeHolder', "Select a formatter"), activeItem: autoFocusPick }); </ins> if (!pick) { // dismissed return undefined;

Discussion:
Have multiple formatters. Choose one as default. "Format with..." command -notice that the default formmater has it specified in parenthesis. However I would also expect that it is preselected by quick pick !
I am always confused when quick pick opens and when the first item isn't the selected one. So, would likely reorder formatters, e.g sort the top pick atop but I am not sure about that...
Changing the order might make sense as that is how quick pick usually behaves. fyi for opinions
The theme selector keeps the order and selects the current theme. I'd go with consistency. !
Change:
"default": false, "description": "%config.followTagsWhenSync%" }, <ins> "git.replaceTagsWhenPull": { "type": "boolean", "scope": "resource", "default": false, "description": "%config.replaceTagsWhenPull%" }, </ins> "git.promptToSaveFilesBeforeStash": { "type": "string", "enum": [

Discussion:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Is it possible to have a setting that would automatically replace the local tags rather than always prompting? Thx
Even, I am also looking for a similar functionality.
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
+1
We are now "moving" a tag to track the last successful build in our CI/CD process for users who don't have a lot of CI/CD or Git experience. We want them to naturally see the tag slide up as the team makes changes and the server succeeds in processing them. It's very jarring to have this modal pop up and have no way of hiding it.
Tomorrow's (2024-02-14) VS Code Insiders release has an updated dialog that has an "Always Replace Local Tag(s)" button. Pressing the button will toggle the so if you wish you can proactively enable this setting in your users/workspace/folder settings. Please give it a try and let me know if you run into any issues. Thanks! <img width="265" alt="image" src=""
Change:
return child.doRefresh(recursive, true); })); } else { <del> this.mapEachChild(child => child.updateVisibility()); return WinJS.TPromise.as(null); </del> <ins> return WinJS.Promise.join(this.mapEachChild((child) => { if (child.needsChildrenRefresh) { return child.doRefresh(recursive, true); } else { child.updateVisibility(); return WinJS.TPromise.as(null); } })); </ins> } });

Discussion:
VSCode Version: 1.25.1 (also tested in latest insiders build) OS Version: Arch Linux x64 Steps to Reproduce: I have created a little demonstrating this bug: the project and run and the debugger - a new VS Code window opens containing a custom view called "BUG DEMO" that custom view and expand all nodes in it - the labels are , and on "INCREASE COUNTER" - now the labels are , and (which is correct) the root node, click "INCREASE COUNTER" and expand the root node again Now the labels are , and - this is incorrect, the grandchild's label should be . You can also see in the Debug console that after clicking "INCREASE COUNTER" the second time and expanding the root node again, only the root and child nodes are fetched, but not the grandchild.
Assigned to July milestone for investigation
Looks like in your code you are using the same id for all nodes. If you are providing an it should be unique. is optional and when it is removed the last step increase counter for all elements
But I'm only using this for one of the 3 nodes:
I just tried with the latest Insiders build and the bug is still there: ! The output in the debug console shows that the three nodes have different IDs , and : Removing the IDs is not a good workaround as it means that the tree loses its collapsed state on every update: !
You are right, it is also reproducible with attribute.
To Verify: Open VS Code on a folder with following structureExpand to see Reveal File C in OS Explorer (Finder/File Explorer) Collapse in VS Code file explorer Rename to Outside VS Code (Finder) Refresh the File Explorer Tree in VS Code Expand in VS Code Verify that Folder B is expanded and showing