jiebi/CodeConvo huggingface dataset:
Change:
I found a few places that "Language" is accidentally spelled "Langauge" in the source. See for the corrections.

Discussion:
return this.sortExtensions(themesExtensions, options); } <del> const isLangaugeBasicExtension = (e: IExtension): boolean => { </del> <ins> const isLanguageBasicExtension = (e: IExtension): boolean => { </ins> return FORCE_FEATURE_EXTENSIONS.indexOf(e.identifier.id) === -1 && (Array.isArray(e.local?.manifest?.contributes?.grammars) && e.local!.manifest!.contributes!.grammars.length > 0); }; if (showBasicsOnly) { <del> const basics = result.filter(isLangaugeBasicExtension); </del> <ins> const basics = result.filter(isLanguageBasicExtension); </ins> return this.sortExtensions(basics, options); } if (showFeaturesOnly) {

return e.local && e.local.manifest && !isThemeExtension(e) <del> && !isLangaugeBasicExtension(e); </del> <ins> && !isLanguageBasicExtension(e); </ins> }); return this.sortExtensions(others, options); }

await this._withSyncedResources([resource]); const modelId = await (await this._getProxy()).detectLanguage(resource.toString(), langBiases, preferHistory, supportedLangs); <del> const langaugeId = this.getLanguageId(modelId); </del> <ins> const languageId = this.getLanguageId(modelId); </ins> const LanguageDetectionStatsId = 'automaticlanguagedetection.perf';

this._telemetryService.publicLog2<ILanguageDetectionPerf, LanguageDetectionPerfClassification>(LanguageDetectionStatsId, { timeSpent: Date.now() - startTime, <del> detection: langaugeId || 'unknown', </del> <ins> detection: languageId || 'unknown', </ins> }); <del> return langaugeId; </del> <ins> return languageId; </ins> } }
Change:
This has been fixed for notebook diffs but is still an issue for text diffs: <img width="115" alt="image" src="https://user-"

Discussion:
import { EventType, addDisposableListener, addStandardDisposableListener, h } from 'vs/base/browser/dom'; import { createFastDomNode } from 'vs/base/browser/fastDomNode'; import { IMouseWheelEvent } from 'vs/base/browser/mouseEvent'; <ins> import { ScrollbarState } from 'vs/base/browser/ui/scrollbar/scrollbarState'; </ins> import { Color } from 'vs/base/common/color'; import { Disposable } from 'vs/base/common/lifecycle'; import { IObservable, autorun, derived, observableFromEvent, observableSignalFromEvent } from 'vs/base/common/observable';

import { DiffEditorEditors } from 'vs/editor/browser/widget/diffEditorWidget2/diffEditorEditors'; import { DiffEditorViewModel } from 'vs/editor/browser/widget/diffEditorWidget2/diffEditorViewModel'; import { appendRemoveOnDispose } from 'vs/editor/browser/widget/diffEditorWidget2/utils'; <del> import { EditorLayoutInfo } from 'vs/editor/common/config/editorOptions'; </del> <ins> import { EditorLayoutInfo, EditorOption } from 'vs/editor/common/config/editorOptions'; </ins> import { LineRange } from 'vs/editor/common/core/lineRange'; import { Position } from 'vs/editor/common/core/position'; import { OverviewRulerZone } from 'vs/editor/common/viewModel/overviewZoneManager';

const scrollTop = scrollTopObservable.read(reader); const scrollHeight = scrollHeightObservable.read(reader); <del> const computedAvailableSize = Math.max(0, layoutInfo.height); const computedRepresentableSize = Math.max(0, computedAvailableSize - 2 * 0); const computedRatio = scrollHeight > 0 ? (computedRepresentableSize / scrollHeight) : 0; const computedSliderSize = Math.max(0, Math.floor(layoutInfo.height * computedRatio)); const computedSliderPosition = Math.floor(scrollTop * computedRatio); viewportDomElement.setTop(computedSliderPosition); viewportDomElement.setHeight(computedSliderSize); </del> <ins> const scrollBarOptions = this._editors.modified.getOption(EditorOption.scrollbar); const state = new ScrollbarState( scrollBarOptions.verticalHasArrows ? scrollBarOptions.arrowSize : 0, scrollBarOptions.verticalScrollbarSize, 0, layoutInfo.height, scrollHeight, scrollTop ); viewportDomElement.setTop(state.getSliderPosition()); viewportDomElement.setHeight(state.getSliderSize()); </ins> } else { viewportDomElement.setTop(0); viewportDomElement.setHeight(0);
Change:
a new integrated terminal /Cmd + Shift + O :bug: only see and in the list of commands
had you run or anything interesting? have not found a repro
!
Can reproduce: <img width="306" alt="image" src="https://user-"<img width="130" alt="image" src="https://user-"
I can repro when I disable screen reader mode and thus don't have that pwsh warning at the top of the buffer. Probably an off by one error where the first line isn't considered
Seems like an off by one in the a11y code, not the command detection as it's showing up in run recent command: <img width="117" alt="image" src="https://user-"<img width="186" alt="image" src="https://user-"
Something that we can test for in April
Still repros with the same original steps, again on Windows
This works, but if I run Ctrl+Shift+O without screen reader optimization enabled or a screen reader attached, I get a weird list of results that appears to be just anything that was written to the terminal: ! The placeholder text about links also doesn't seem right
Yeah, when you don't have screen reader mode on, runs which presents any links found within the terminal. We consider words to be links. As you can see here, if there are more well formed links, we present them at the top. !
FWIW, this behavior was pretty unexpected to me (and 'workspace search' also didn't seem to describe the quickpick items I was looking at). Personally if there aren't actual links in the terminal output I wouldn't expect them to be in the quickpick items...

Discussion:
return; } line = this._bufferTracker.bufferToEditorLineMapping.get(line); <del> if (!line) { </del> <ins> if (line === undefined) { </ins> return; } return line + 1;
Change:
Type: <bBug</bIncluding a non-existent file in C++ causes an error that does not get matched. The problem is that the regex will match "error" but not "fatal error" (or "fatal error" with 2 spaces in the case of invoking msbuild instead of cl). VS Code version: Code - Insiders 1.77.0-insider (, 2023-03-24T05:23:09.316Z) 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 --
I have a PR available for this:
I don't get a useful message about the problem in the problems view: <img width="317" alt="image" src=""Test task (for Windows at least):
I took a look at the PR for this to see if the problem matcher ever includes a message, and it does. The PR adds an optional group but doesn't increment the group numbers that each part of the problem is set as. I'm not sure how this would work for an optional group.
Please feel free to mark as verified if this is good enough.
pretty sure you found a bug. changing to will exclude the group from the result and not mess with the group indexes.
I do get a useful message now: <img width="1413" alt="image" src=""However when running Alex's provided task for the first time, I was prompted about which problem matcher I wanted to run on the output, and I don't think I should have to specify that again if my task already included a specific problem matcher

Discussion:
private fillDefaults(): void { this.add('msCompile', { <del> regexp: /^(?:s+d+>)?(S.*)((d+|d+,d+|d+,d+,d+,d+))s*:s+(error|warning|info)s+(w+d+)s*:s*(.*)$/, </del> <ins> regexp: /^(?:s*d+>)?(S.*)((d+|d+,d+|d+,d+,d+,d+))s*:s+((fatal +)?error|warning|info)s+(w+d+)s*:s*(.*)$/, </ins> kind: ProblemLocationKind.Location, file: 1, location: 2,

name: 'msCompile', label: localize('msCompile', 'Microsoft compiler problems'), owner: 'msCompile', <ins> source: 'cpp', </ins> applyTo: ApplyToKind.allDocuments, fileLocation: FileLocationKind.Absolute, pattern: ProblemPatternRegistry.get('msCompile')
Change:
Type: <bBug</bIncluding a non-existent file in C++ causes an error that does not get matched. The problem is that the regex will match "error" but not "fatal error" (or "fatal error" with 2 spaces in the case of invoking msbuild instead of cl). VS Code version: Code - Insiders 1.77.0-insider (, 2023-03-24T05:23:09.316Z) 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 --
I have a PR available for this:
I don't get a useful message about the problem in the problems view: <img width="317" alt="image" src=""Test task (for Windows at least):
I took a look at the PR for this to see if the problem matcher ever includes a message, and it does. The PR adds an optional group but doesn't increment the group numbers that each part of the problem is set as. I'm not sure how this would work for an optional group.
Please feel free to mark as verified if this is good enough.
pretty sure you found a bug. changing to will exclude the group from the result and not mess with the group indexes.
I do get a useful message now: <img width="1413" alt="image" src=""However when running Alex's provided task for the first time, I was prompted about which problem matcher I wanted to run on the output, and I don't think I should have to specify that again if my task already included a specific problem matcher

Discussion:
private fillDefaults(): void { this.add('msCompile', { <del> regexp: /^(?:s*d+>)?(S.*)((d+|d+,d+|d+,d+,d+,d+))s*:s+((fatal +)?error|warning|info)s+(w+d+)s*:s*(.*)$/, </del> <ins> regexp: /^(?:s*d+>)?(S.*)((d+|d+,d+|d+,d+,d+,d+))s*:s+((?:fatal +)?error|warning|info)s+(w+d+)s*:s*(.*)$/, </ins> kind: ProblemLocationKind.Location, file: 1, location: 2,
Change:
This is pretty nitpicky, but I notice that if I say "Provide Feedback" in the remote explorer, the first entry for codespaces takes me to a github community page. However, since the icon "Provide Feedback" was a twitter icon, I thought that all options would take me to twitter. Is there a more generic icon that we can use? <img width="216" alt="image" src="https://user-"
Good catch, cc as I think we previously discussed not wanting to send users to twitter for feedback anymore. What is the preferred feedback mechanism now? (Relatedly, should we consolidate Provide Feedback and Report Issue?)
If this is for Codespaces, I believe the GH Discussions is still the preferred spot: I also think it makes sense to combine Provide Feedback & Report Issue into one node!
Yeah for all our other remote extensions the Provide Feedback node still goes to twitter, I propose that we deprecate that in favor of Report Issue (for codespaces, their feedback and report issue items both go to the same GH discussions). Any concerns
Sounds good to me!
Tasks: [x] Remove from remote help [x] Remove entries for [x] Codespaces [x] Remote Repos [ ] ~Remote Tunnels~ [ ] ~Remote SSH~ [x] WSL [x] Dev Containers
Slight edit--Codespaces' Provide Feedback and Issues links go to the GH discussions tracker, but Codespaces' Report Issue command opens the builtin issue reporter prefilled to the GitHub Codespaces extension. Clicking the button in the issue reporter then inexplicably opens the Windows file explorer. <img width="387" alt="image" src="https://user-"I believe Codespaces actually wants issues to be reported in GH discussions instead of the VS Code issue tracker, so what I'd suggest is: we introduce a new optional property which Codespaces would point to their GH discussions tracker all other remotes would not provide this property we would not show the Provide Feedback item anymore since Report Issue will do the same thing cc for feedback on the proposed change to the Codespaces extension
those changes sound good to me

Discussion:
return Promise.all(this.values.map(async (value) => { return { label: value.extensionDescription.displayName || value.extensionDescription.identifier.value, <del> description: '', </del> <ins> description: await value.url, </ins> extensionDescription: value.extensionDescription }; }));
Change:
On Safari/Codespace Open a notebook Open settings Switch to notebook Press enter https://user-

Discussion:
constructor() { super({ id: SETTINGS_EDITOR_COMMAND_FOCUS_CONTROL, <del> precondition: CONTEXT_SETTINGS_ROW_FOCUS, </del> <ins> precondition: ContextKeyExpr.and(CONTEXT_SETTINGS_EDITOR, CONTEXT_SETTINGS_ROW_FOCUS), </ins> keybinding: { primary: KeyCode.Enter, weight: KeybindingWeight.WorkbenchContrib,
Change:
Embedding unicode characters into our sources has shown a slowdown in performance.
If this was the cause of , then it's a real good catch!
yes, it looks like the cause at least of the slowdown between March 9th and 10th around the of workbench main.
Before: ellapsed: 810ms (fastest), 1294ms (slowest), 841ms (median) After: ellapsed: 788ms (fastest), 1204ms (slowest), 805ms (median)

Discussion:
})); disposables.add(onKeyDown.event(e => { <del> // allow-any-unicode-next-line if (e.key === 'Process' || /[가-힇ㄱ-ㅎㅏ-ㅣぁ-ゔァ-ヴー々〆〤一-龥]/.test(e.key)) { </del> <ins> if (e.key === 'Process' || /[uac00-ud787u3131-u314eu314f-u3163u3041-u3094u30a1-u30f4u30fcu3005u3006u3024u4e00-u9fa5]/u.test(e.key)) { </ins> if (e.code === 'Backspace') { imeBackSpace = true; } else if (!e.code.includes('Key')) {
Change:
For links we support perma link and head urls. For we only support perma links but I observe myself to need head links more than permalinks. We should add those. Also, for file and folders with whitespace, the whitespace should be encoded, just like we do for the links we generate.
IMO links should be head links rather than permalinks. We could support both but I want to avoid clutter if possible. Also, I do not see that we encode the whitespace for either or links that we generate--will look into fixing for all our link code.
Verification: pre-release of GitHub Pull Requests extension on desktop a desktop git clone of a GitHub repository on desktop a file a link that the link is a HEAD link (i.e. does not point to a specific commit sha) a GitHub repository on web (e.g. ) steps 2-4

Discussion:
try { const permalink = getLink(gitAPI, useSelection, getVscodeDevHost(), 'headlink', context, includeRange); if (permalink) { <del> return vscode.env.clipboard.writeText(permalink); </del> <ins> return vscode.env.clipboard.writeText(encodeURI(permalink)); </ins> } } catch (err) { vscode.window.showErrorMessage(err.message);
Change:
Does this issue occur when all extensions are disabled?: Yes VS Code Version: 1.77.0 OS Version: Windows 10 Enterprise 21H2 .2728 Steps to Reproduce: to a HTML file with a -block with some CSS rules a new line getting to the end of the file (correct) and to the end of the -block before the closing tag (issue!)
I can not reproduce ! The option dos only impact the last new line. The new line inserted before comes from the setting Can you provide an example. Make sure you are using the built-in HTML formatter.
You have to use a -block. It will not happen with any other HTML-Element.

Discussion:
// perform a html format and apply changes to a new document const htmlMode = languageModes.getMode('html')!; const htmlEdits = await htmlMode.format!(document, formatRange, formattingOptions, settings); <del> const htmlFormattedContent = TextDocument.applyEdits(document, htmlEdits); </del> <ins> let htmlFormattedContent = TextDocument.applyEdits(document, htmlEdits); if (formattingOptions.insertFinalNewline && endOffset === content.length && !htmlFormattedContent.endsWith('n')) { htmlFormattedContent = htmlFormattedContent + 'n'; htmlEdits.push(TextEdit.insert(endPos, 'n')); } </ins> const newDocument = TextDocument.create(document.uri + '.tmp', document.languageId, document.version, htmlFormattedContent); try { // run embedded formatters on html formatted content: - formatters see correct initial indent

} else { formatSettings.contentUnformatted = 'script'; } <del> if (formatParams.insertFinalNewline) { formatSettings.endWithNewline = true; } </del> merge(formatParams, formatSettings); return htmlLanguageService.format(document, range, formatSettings); },

}); test('EndWithNewline', async () => { <del> const options : FormattingOptions = FormattingOptions.create(2, true); </del> <ins> const options: FormattingOptions = FormattingOptions.create(2, true); </ins> options.insertFinalNewline = true; await assertFormat('<html><body><p>Hello</p></body></html>', '<html>nn<body>n  <p>Hello</p>n</body>nn</html>n', {}, options); await assertFormat('<html>|<body><p>Hello</p></body>|</html>', '<html><body>n  <p>Hello</p>n</body></html>', {}, options); <ins> await assertFormat('<html>|<body><p>Hello</p></body></html>|', '<html><body>n  <p>Hello</p>n</body>nn</html>n', {}, options); </ins> await assertFormat('<html><head><script>nvar x=1;n</script></head></html>', '<html>nn<head>n  <script>n    var x = 1;n  </script>n</head>nn</html>n', {}, options); });
Change:
Add the following user setting: . Open a folder/workspace that contains a git repository and the SCM view fill up with multiple instances of the same repository.

Discussion:
private updateBranchProtectionMatcher(): void { const scopedConfig = workspace.getConfiguration('git', Uri.file(this.repository.root)); <del> const branchProtectionGlobs = scopedConfig.get<string[]>('branchProtection')!.map(bp => bp.trim()).filter(bp => bp !== ''); </del> <ins> const branchProtectionConfig = scopedConfig.get<unknown>('branchProtection') ?? []; const branchProtectionValues = Array.isArray(branchProtectionConfig) ? branchProtectionConfig : [branchProtectionConfig]; const branchProtectionGlobs = branchProtectionValues .map(bp => typeof bp === 'string' ? bp.trim() : '') .filter(bp => bp !== ''); </ins> if (branchProtectionGlobs.length === 0) { this.isBranchProtectedMatcher = undefined;
Change:
Version: 1.77.1 Commit: Date: 2023-04-04T23:20:37.202Z Electron: 19.1.11 Chromium: 102.0.5005.196 16.14.2 V8: 10.2.154.26-electron.0 OS: Linux x64 5.15.0-69-generic Sandboxed: No install code from start from terminal Lot of log output is shown. See blow shows that the log level is Info

Discussion:
this.logService.warn(logMsg); break; case Severity.Info: <del> this.logService.info(logMsg); </del> <ins> this.logService.trace(logMsg); </ins> break; } }
Change:
Type: <bBug</bWhen a terminal is reused by different tasks, the in it's terminal tabs entry is never updated to reflect the current task that is reusing it. One would expect that just as how the label for the terminal's tab entry updates to match the for the latest task, that it's icon would similarly be updated to provide a consistent visual and textual feedback of the terminal's current task status. Steps to Reproduce: Using the example included below: Close all terminals --OR Close all terminals -<details</summary</detailsExpected: the task icon should change from :debug-start: to :debug-stop: ! Observed: the task icon remains the same as whatever it was first initialized to ! <details<summaryDOM HTML Snippet</summary</detailsVS Code version: Code - Insiders 1.78.0-insider (, 2023-04-05T05:27:51.301Z) OS version: Linux x64 5.19.0-38-generic Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Perhaps this function in has something to do with this?
I'll go and try to fix this
Looks like it's now working with the insiders release! VS Code version: Code - Insiders 1.78.0-insider (, 2023-04-20T05:21:04.496Z) OS version: Linux x64 5.19.0-38-generic Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details

Discussion:
this._initialCwd = value; this._cwd = this._initialCwd; this._setTitle(this.title, TitleEventSource.Config); <ins> this._icon = this._shellLaunchConfig.attachPersistentProcess?.icon || this._shellLaunchConfig.icon; this._onIconChanged.fire({ instance: this, userInitiated: false }); </ins> break; case ProcessPropertyType.Title: this._setTitle(value ?? '', TitleEventSource.Process);
Change:
<!-- 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.77.1 OS Version: Windows 10 Steps to Reproduce: some reason this is fine on documents which are already open when VSCode starts, so start by making a new file. Don't save it: once it has an extension, autodetection stops kicking in. some markdown. Eventually the screen reader announces that the language was autodetected. a single letter, pause, and the screen reader will announce that the language was autodetected as markdown again. Continue typing single characters and waiting and it continues to do the same. This also does the same if you just type normally, but the above is a repro that's likely to work even with typing echo on. I'd expect it to announce it only when it changes.
do you know who owns language detection?
owns it :) Good catch - it seems like we should announce only if the Detected Language changes.

Discussion:
} const lang = await this.languageDetectionService.detectLanguage(this.textEditorModelHandle); <del> if (lang && !this.isDisposed()) { </del> <ins> const prevLang = this.getLanguageId(); if (lang && lang !== prevLang && !this.isDisposed()) { </ins> this.setLanguageIdInternal(lang, LanguageDetectionLanguageEventSource); const languageName = this.languageService.getLanguageName(lang); <del> if (languageName) { this.accessibilityService.alert(localize('languageAutoDetected', "Language {0} was automatically detected and set as the language mode.", languageName)); } </del> <ins> this.accessibilityService.alert(localize('languageAutoDetected', "Language {0} was automatically detected and set as the language mode.", languageName ?? lang)); </ins> } }
Change:
<!-- 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. --- 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. --- Microsoft Windows 11 Pro 10.0. N/A Build Not sure if this is intended behavior or not but I think if I use the button it should create and show the repository. If is set to , the repository is actually created but nothing is shown in VsCode I understand that this option is for auto-detect and it's kind of logical, but should it affect the action? !
thank you very much for filing this issue. Setting to disables repository detection independent whether it already exists or it has been created using VS Code. While this is the intended behaviour, I agree that we could probably make this experience better.

Discussion:
const choices = [open, openNewWindow]; if (!askToOpen) { <ins> await this.model.openRepository(repositoryPath); </ins> return; }