jiebi/CodeConvo huggingface dataset:
Change:
this.instantiationService.createInstance(SwitchToPreReleaseVersionAction, true), this.instantiationService.createInstance(ManageExtensionAction) ]; <del> const extensionHoverWidget = this.instantiationService.createInstance(ExtensionHoverWidget, { target: root, position: this.options.hoverOptions.position }, extensionStatusIconAction, reloadAction); </del> <ins> const extensionHoverWidget = this.instantiationService.createInstance(ExtensionHoverWidget, { target: root, position: this.options.hoverOptions.position }, extensionStatusIconAction); </ins> const widgets = [ recommendationWidget,

Discussion:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --Hello, I searched for an existing ticket with , but didn't find anything related. <!-- Describe the feature you'd like. --Prior to v1.72.0, the extension sidebar showed which version an extension will be updated to. And when hovering over the extension in the sidebar, or opening the extension in a tab, you could see the currently installed one. That way you could see for example if an update is a major, minor, or patch update, and depending on that dig into the release notes or not. Further in the past, IIRC, the extension sidebar even showed both, installed and target version, which was even more convenient. Now with v1.72.0, I don't see anywhere the target version of an extension update. Many extensions don't keep a proper changelog, so that's not a reliable place to check. Here's an example for vscode-icons, a very popular extension with 12 million installs: ! Only when going to the Marketplace webpage () we see the target version: ! =Feature request: Please make the target version for extension updates visible inside of VS Code again.
Latest version is now shown in the hover. Update button in the extension editor shows the version.
Change:
import { localize } from 'vs/nls'; import { InlayHintsHover } from 'vs/editor/contrib/inlayHints/browser/inlayHintsHover'; import { BugIndicatingError } from 'vs/base/common/errors'; <ins> import { HoverAction } from 'vs/base/browser/ui/hover/hoverWidget'; </ins> export class RenderedContentHover extends Disposable {

Discussion:
Testing Once again, I'm not sure what the norms are here, but would it be useful to have the actions in the status bar show in the accessibly view? <img width="607" alt="image" src=""
Hi yes that would make sense. Good point!
Change:
} function prepareBracketForRegExp(str: string): string { <del> const escaped = escapeRegExpCharacters(str); // This bracket pair uses letters like e.g. "begin" - "end" (see https://github.com/microsoft/vscode/issues/132162) const needsWordBoundaries = (/^[w ]+$/.test(str)); return (needsWordBoundaries ? `b${escaped}b` : escaped); </del> <ins> let escaped = escapeRegExpCharacters(str); // These bracket pair delimiters start or end with letters // see https://github.com/microsoft/vscode/issues/132162 https://github.com/microsoft/vscode/issues/150440 if (/^[w ]+/.test(str)) { escaped = `b${escaped}`; } if (/[w ]+$/.test(str)) { escaped = `${escaped}b`; } return escaped; </ins> } export class LanguageAgnosticBracketTokens {

Discussion:
I am the maintainer of VS Code basic latex language support. The language defines / as a bracket pair. This leads to wrongly highlight <img width="415" alt="Capture d’écran 2022-05-26 à 08 07 09" src="https://user-"I believe this is related to fixed it in by surrounding brackets using letters only with . However, in LaTeX every command starts with and the fix does not apply. This issue occurs on Version: 1.67.2 and also on Version: 1.68.0-insider (Universal) Commit: Date: 2022-05-25T05:16:10.689Z Electron: 17.4.4 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Darwin x64 21.5.0 This problem was originally reported at
should be extended to check if the bracket starts/ends with a word. Only at those borders, should be . Should be easy to implement. I'm open for a PR here ;)
hey I am a beginner in open source contributions . Could you please guide me how too start contributing
I'd start here:
Hi I'm just starting out with open source contributions and just finished reading the how to guide you linked in this thread. I'm having some trouble understanding exactly what the issue is, could you please explain it a bit more? Is rangledot supposed to be highlighted as a whole?
This issue is actually already handled by PR , which will be merged for the July 2022 release.
Verification steps: Install the LaTeX extension Verify that and is matched, but not with in
I would personally highly go against this fix As it would disallow word based brackets inside word strings with no alternative (other than to reinvent the bracket highlighter again) I have no example of any language being affected But I would question the arbitration decesion to limit such function Instead, I think LaTeX should fix their bug (which was present before coloured brackets) by just disallowing/allowing certain word based bracket scopes via the and sections in !
Let's discuss this in a separate issue once this actually is a problem!
Change:
private _getActions(scope: EnvironmentVariableScope | undefined): ITerminalStatusHoverAction[] { return [{ <del> label: localize('showEnvironmentContributions', "Show environment contributions"), </del> <ins> label: localize('showEnvironmentContributions', "Show Environment Contributions"), </ins> run: () => this._commandService.executeCommand(TerminalCommandId.ShowEnvironmentContributions, scope), commandId: TerminalCommandId.ShowEnvironmentContributions }];

Discussion:
Testing microsoft/vscode-python ! I would use capital casing. Also the links seem cut off on the right
Do you mean the sentence after ? That's meant to be sentence case as it describes what the extension wants to do: <img width="485" alt="Screenshot 2024-06-25 at 7 49 23 AM" src=""
No this: ! I was zoomed in.
I meant for your capital case suggestion. For the zoom I created which was a dupe of
Yeah I felt it should be "Relaunch Terminal", like a button. But maybe there was a discussion against it since its a link?
Moving this to VS Code as this hover is not controlled by python extension.
thoughts?
Seems like we aren't consistent here. But I'd agree that we generally should use capital casing for commands. I think I've seen that pattern used more often than not. ! !
Change:
line-height: 14px; background-color: inherit; justify-content: center; <del> width: calc(100% - 16px); </del> <ins> width: calc(100% - 19px); </ins> } .monaco-workbench .part.titlebar>.titlebar-container>.window-title>.title-menu .action-item.quickopen>.action-label.search>.search-icon { font-size: 14px; opacity: .8; <del> padding-right: 3px; </del> <ins> padding: 0 3px; } .monaco-workbench .part.titlebar>.titlebar-container>.window-title>.title-menu .action-item.quickopen>.action-label.search>.search-label { overflow: hidden; text-overflow: ellipsis; </ins> } .monaco-workbench .part.titlebar>.titlebar-container>.window-title>.title-menu .action-item.quickopen>.all-options>.action-label {

Discussion:
Trying Perhaps we could default to some subset of the prompt text under some media query or other window size condition. One possible option would be to shorten the [Action | Folder name] pattern to just the action. E.g. "Search hello-world" -"Search" <img width="461" alt="CleanShot 2022-05-13 at 09 59 13 src="https://user-"<img width="472" alt="CleanShot 2022-05-13 at 10 03 30 src="https://user-"cc for other ideas
Small update: based on standup-feedback I swapped "Search" with the corresponding icon. That should give some more room but the problem still exists... I lean towards using the usual ellipsis for text overflow <img width="473" alt="Screenshot 2022-05-16 at 14 02 46" src="https://user-"
This is how it looks with ellipsis. *it actually looks better - the recording shows some padding issues when space is tight https://user-
Looks great! Especially if there more padding L/R per your edit.
Change:
const extensionsToDisable: IExtensionIdentifier[] = []; const userMigratedSystemExtensions: IExtensionIdentifier[] = [{ id: BetterMergeId }]; <del> const enableProposedApiForAll = !this._environmentService.isBuilt || (!!this._environmentService.extensionDevelopmentPath && product.nameLong.indexOf('Insiders') >= 0); </del> const enableProposedApiFor: string | string[] = this._environmentService.args['enable-proposed-api'] || []; <ins> const enableProposedApiForAll = !this._environmentService.isBuilt || (!!this._environmentService.extensionDevelopmentPath && product.nameLong.indexOf('Insiders') >= 0) || (enableProposedApiFor.length === 0 && 'enable-proposed-api' in this._environmentService.args); </ins> for (const extension of allExtensions) { const isExtensionUnderDevelopment = this._environmentService.isExtensionDevelopment && extension.extensionLocation.scheme === Schemas.file && extension.extensionLocation.fsPath.indexOf(this._environmentService.extensionDevelopmentPath) === 0; // Do not disable extensions under development

Discussion:
testing : I was running "code-insiders" with the "--enable-proposed-api" option without noticing that the option requires an extension ID. This should be fixed either by reporting an error and aborting "code", or by interpreting a missing extension ID as the semantics "enable proposed API for any extension"
Please support the latter
:+1: I was in an endless loop running and then reading the error message . Please don't make me find out the extension id.
Yeah, the error message should simply print the extension id...
fixed vai
Change:
return localize('extensions', "Extensions"); } }, <del> overrideStyles: { listBackground: SIDE_BAR_BACKGROUND }, </del> <ins> overrideStyles: this.getLocationBasedColors().listOverrideStyles, </ins> openOnSingleClick: true }) as WorkbenchPagedList<IExtension>; this._register(this.list.onContextMenu(e => this.onContextMenu(e), this));

Discussion:
Sometimes the tree sticky show shadow does not show. Make sure they use the proper overrides and that there is a default color if none is provided
are there any validation steps here?
verified- the scm sticky scroll showed on insiders, but not stable.
Change:
if (type === AssetType.VSIX) { return { <del> uri: `${version.fallbackAssetUri}/${type}?redirect=true`, fallbackUri: `${version.fallbackAssetUri}/${type}` </del> <ins> uri: `${version.fallbackAssetUri}/${type}?redirect=true&install=true`, fallbackUri: `${version.fallbackAssetUri}/${type}?install=true` </ins> }; }

Discussion:
The Marketplace extension query now returns two Asset URI’s: and . Asset downloads should work the following way: VSIXPackage Use with the param. Fallback to without the param. Other assets Use without the param. Fallback to without the param.
Change:
filter(stat: ExplorerItem, parentVisibility: TreeVisibility): boolean { // Add newly visited .gitignore files to the ignore tree <del> if (stat.name === '.gitignore' && this.ignoreTreesPerRoot.has(stat.resource.toString())) { </del> <ins> if (stat.name === '.gitignore' && this.ignoreTreesPerRoot.has(stat.root.resource.toString())) { </ins> this.processIgnoreFile(stat.root.resource.toString(), stat.resource, false); return true; }

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. --Steps to Reproduce: a .gitignore file that excludes node_modules Result: Nothing happens. Do the same in Stable and the folder is hidden. Here is a picture with Insiders on the left and Stable on the right: !
Change:
return; } const errorDetails = isPanelChat && response.errorDetails ? ` ${response.errorDetails.message}` : ''; <del> status(renderStringAsPlaintext(responseContent) + errorDetails); </del> <ins> const plainTextResponse = renderStringAsPlaintext(new MarkdownString(responseContent)); status(plainTextResponse + errorDetails); </ins> } }

Discussion:
Have a response that contains references to code, e.g. : ! Start screen reader and click on the response. Notice how the full URLs are being read out aloud which are very long. Verbatim text: I think this stems from the fact that we just take the response as string here:
Btw I have a similar challenge for the text-to-speech integration where I am thinking about converting the markdown string to a plain text string using : But I did notice that this would remove some text, such as ordered list.
made a good point in our standup today: why are we not leveraging the HTML screen reader support for chat items but use ?
The HTML screen reader support requires users to enter different modes to navigate - browse/focus mode. Feedback from screen reader users suggested this is not user friendly. Users will examine content in detail in the chat accessible view, not here. Providing an overview of the response with aria alert is desired. This is similar to how sighted users see the response streaming in. Screen reader users press escape if they don't wish to hear the content.
I agree it's not good that it's reading the full URLs. A similar problem is here and my solution to that will be to remove those links and provide an alternate way of setting any keybindings which are undefined.
Potential verification found: I asked for the location of some code, and after Copilot finished typing out the response, it announced the entire response, including all the link text and full command IDs.
LGTM now. I might've forgotten to update something.
A screenshot of the text that was announced would help to know if this was fixed or not
nvm. The symbols are good but the URLs still expand !
unclear how this could be happening as I'm using
figured it out
It is still reading the complete path for me.
and the complete path is expected. what's not expected is these chars
going to see if I can repro on windows
does not reproduce for me on windows either . It makes no sense that this would happen - , we literally parse that stuff out. could you pls debug in oss here? !
I believe the issue is fixed now. I notice that when the announcement is read out that the links are now announced correctly. When I click on the response, the links are read with the Markdown formatting again, but I believe that this behaviour is out of scope of the issue.
Change:
: { element, collapsible: element.test.expand !== TestItemExpandState.NotExpandable, <del> collapsed: isCollapsedInSerializedTestTree(serialized, element.test.item.extId) ?? element.depth > 0 ? ObjectTreeElementCollapseState.PreserveOrCollapsed : ObjectTreeElementCollapseState.PreserveOrExpanded, </del> <ins> collapsed: element.test.item.error ? ObjectTreeElementCollapseState.PreserveOrExpanded : (isCollapsedInSerializedTestTree(serialized, element.test.item.extId) ?? element.depth > 0 ? ObjectTreeElementCollapseState.PreserveOrCollapsed : ObjectTreeElementCollapseState.PreserveOrExpanded), </ins> children: getChildrenForParent(serialized, rootsWithChildren, element), } ));

Discussion:
Testing It shows the error's message, but doesn't make explicit that there was an error thrown. ! This is from:
Change:
quickPick.busy = true; quickPick.show(); <del> quickPick.items = await this._createQuickPickItems(); quickPick.busy = false; </del> <ins> const items = await this._createQuickPickItems(); </ins> // Set initial selection let selectedItems: HistoryItemRefQuickPickItem[] = []; if (this._historyItemsFilter === 'all') { selectedItems.push(this._allQuickPickItem); <del> quickPick.selectedItems = [this._allQuickPickItem]; </del> } else if (this._historyItemsFilter === 'auto') { selectedItems.push(this._autoQuickPickItem); <del> quickPick.selectedItems = [this._autoQuickPickItem]; </del> } else { <del> for (const item of quickPick.items) { if (item.type === 'separator') { </del> <ins> let index = 0; while (index < items.length) { if (items[index].type === 'separator') { index++; </ins> continue; } <del> if (this._historyItemsFilter.some(ref => ref.id === item.id)) { selectedItems.push(item); </del> <ins> if (this._historyItemsFilter.some(ref => ref.id === items[index].id)) { const item = items.splice(index, 1) as HistoryItemRefQuickPickItem[]; selectedItems.push(...item); } else { index++; </ins> } } <del> quickPick.selectedItems = selectedItems; </del> <ins> // Insert the selected items after `All` and `Auto` items.splice(2, 0, { type: 'separator' }, ...selectedItems); </ins> } <ins> quickPick.items = items; quickPick.selectedItems = selectedItems; quickPick.busy = false; </ins> return new Promise<'all' | 'auto' | ISCMHistoryItemRef[] | undefined>(resolve => { this._store.add(quickPick.onDidChangeSelection(items => { const { added } = delta(selectedItems, items, (a, b) => compare(a.id ?? '', b.id ?? ''));

Discussion:
Type: <bFeature Request</bI have selected , and but when I bring up the picker again I can't see this until I filter. ! Workaround (assuming the items I previously selected have a string in common): ! VS Code version: Code - Insiders 1.94.0-insider (, 2024-09-10T05:04:21.546Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
/assign
Change:
commandManager.register(new ConfigurePluginCommand(pluginManager)); commandManager.register(new LearnMoreAboutRefactoringsCommand()); commandManager.register(new TSServerRequestCommand(lazyClientHost)); <ins> commandManager.register(new OpenJsDocLinkCommand()); </ins> }

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: see below, pulled from the "Help About" dialog. Also confirmed in 1.71.2. OS Version: see below, pulled from the "Help About" dialog. Steps to Reproduce: above VSCode Insiders build. (Instructions don't require system path to be updated.) a directory in WSL, say . , where is the distro of your choice. the WSL extension as prompted and reload. the editor and run , where is the distro of your choice. (Steps 2-4 were just to initialize some VSCode state.) a new file in that directory with the following contents: restart editor. (Works either way.) over above. tooltip will appear with "some thing linking Foo" where is hyperlinked. Click the hyperlink in the tooltip. attempts to open a file at the path in the parent Windows OS, outside of any WSL distro. Note that this reproduces both with the WSL extension enabled the whole time (skipping step 5) and with it disabled at step 5.
Did this get missed?
I have the same issue with VSCode running in WSL2 (Ubuntu)
Same issue here, using a remote connection to a VM running on Hyper-V. Host OS is Windows, guest OS is Ubuntu 22.04. It only happens when clicking the link in the tooltip. Using directly in the editor works as expected.
Still seeing this issue. Looking forward to this getting resolved soon.

<!-- 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:
class GitConfigParser { private static readonly _lineSeparator = /r?n/; <del> private static readonly _propertyRegex = /^s*(w+)s*=s*(.*)$/; </del> <ins> private static readonly _propertyRegex = /^s*(w+)s*=s*"?([^"]+)"?$/; </ins> private static readonly _sectionRegex = /^s*[s*([^]]+?)s*("[^"]+")*]s*$/; static parse(raw: string): GitConfigSection[] {

Discussion:
Issue Type: <bBug</bI believe there is an issue with parsing the '.gitmodules' file. If the value of the 'path' parameter of a submodules is enclosed in quotation marks ", the submodule is not detected as git repository. The quotation marks are necessary, because the parameter value contains the character # and the remaining content of the line is otherwise interpreted as comment by git. Without the quotaion marks Visual Studio Code detects the submodules as repositories, but git cannot perform submodule commands. Examplary content of '.gitmodules' - file where detection is not working, but git is: Examplary content of '.gitmodules' - file where detection is working, but git is not: VS Code version: Code 1.69.2 (, 2022-07-18T16:12:52.460Z) OS version: WindowsNT x64 10.0. Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (17)</summaryExtensionVersion ------ gitignore0.9.0 doxdocgen1.4.0 xml2.5.1 gitlens12.1.2 auto-close-tag0.5.14 auto-complete-tag0.1.0 auto-rename-tag0.1.10 better-cpp-syntax1.15.19 git-graph1.30.0 csharp1.25.0 python2022.12.0 vscode-pylance2022.8.10 cmake-tools1.11.26 cpptools1.11.5 cpptools-extension-pack1.2.0 vscode-fileutils3.5.0 cmake0.0.17 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.70.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Hello, I have updated the Visual Studio Code to version 1.70.1 and the issue still exists.

Version: 1.70.1 (user setup) Commit: Date: 2022-08-10T06:08:33.642Z Electron: 18.3.5 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Windows_NT x64 10.0.
Change:
blockClassNames.push('handled'); } if (modifiedBaseRange === activeModifiedBaseRange) { <del> blockClassNames.push('active'); </del> <ins> blockClassNames.push('focused'); </ins> } blockClassNames.push('result');

Discussion:
I really like how I can see the word-level change per line now in the merge editor, but shouldn't the colors be identical to the diff editor? !
I agree the new color needs to be tweaked. Would you also use the green background?
I think making this look as close as a diff editor if possible would be nice because I am so used at looking at diffs with their color coding. //cc
Change:
/** * Log the given info message to the channel. * <del> * Messages are only printed when the user has enabled info logging. </del> <ins> * Messages are only logged when the {@link LogOutputChannel.logLevel log level} is {@link LogLevel.Info info} or lower. </ins> * * @param message info message to log */

Discussion:
Testing the API lacks an explanation of the interaction between channel log levels and app log levels. the comments of the individual log methods all have the form "Messages are only printed when the user has enabled xxx logging" but nowhere is explained how "xxx logging enablement" is related to the log level. I would rather expect something like "xxx messages are only logged when the log level is xxx or lower."