jiebi/CodeConvo huggingface dataset:
Change:
enableFindWidget: true, }, contentOptions: { <del> localResourceRoots: [] </del> <ins> localResourceRoots: [], allowScripts: true </ins> }, extension: undefined },

Discussion:
Since we open release notes (by default) on each release, there should be a visible way to opt-out. Either a checkbox similar to the Welcome experience, or a markdown command link. re:
I think having a setting to toggle this would be best. The release notes is just a markdown preview so we can't add any UI elements to it, unlike the Welcome page which is different.
We do have a setting already , but we have LOTS of settings. Even though it is markdown, we could still add a command link to the text that would run a new command to toggle the setting.
I don't know, this seems pretty obvious: !
Its friction -- if the release notes pops up and aggravates me, I have to take much extra energy to go looking for the setting (even though it is an easy one to find)
I could see maybe adding a menu item in the ... in the top right, but doubt that is discoverable. Placing it inside of the preview feels a bit odd like an unsubscribe link.
On the constrain of adding UI to the notes: The relnotes manager output already has a patch that runs to and handles . Might the same be used to inject an opt-out checkbox or link inside the header? A common UX to test would be a "Don't show again" link/button we have in notifications (and elsewhere?).
One heuristic could be that if we see the release notes are closed within 5 seconds of them opening, we show a notification asking the user whether they want to see them in the future. The downside is that it trades release note fatigue for notification fatigue
I totally agree. Just not sure of the right UX here.
Here a few different ideas: ! ! This would take some engineering effort as it's not easily supported in plain markdown, but placing a small navigation bar at the bottom so that it's always visible. Downside is if you want to see the release notes it's annoying to see !
I like the checkbox since it's a pretty standard way of doing this... Maybe at the top (2) is best?
When lands, a wording could be "Show release notes for monthly updates." to indicate the monthly frequency to set expectations.
I prefer # 2
Another tweet about this: I prefer because it aligns with how we show the checkbox for the welcome page too.

I prefer # 3 too because it does not interrupt the flow for people reading the release notes Another possible wording based on 's could be "Show release notes for major updates"
Currently is of "application" scope (), meaning that I cannot set it to "false" in section of a file. Can it be scope? It's slightly different from the original topic. Let me know if you want me to open a separate issue for it.
!
Do we want to show it at the top so prominently? Feels like it breaks the layout and we would like users at least glancing at the release notes.
IMO it should at least be under the or under the first paragraph. Agreed that it feels like it breaks the layout.
!
This looks better to me. Thanks
Change:
override cellAt(index: number) { return viewModel.cellAt(index)!; } override getCellIndex(cell: ICellViewModel) { return viewModel.getCellIndex(cell); } override getCellsInRange(range?: ICellRange) { return viewModel.getCellsInRange(range); } <ins> override getCellByHandle(handle: number) { return viewModel.getCellByHandle(handle); } </ins> override getNextVisibleCellIndex(index: number) { return viewModel.getNextVisibleCellIndex(index); } getControl() { return this; } override get onDidChangeSelection() { return viewModel.onDidChangeSelection as Event<any>; }

Discussion:
From
The core might have heuristics of if/when should be called, maybe this test can be turned into a unit test first?
Was just looking at this. That might make sense too, but it also seems to make sense to test this as an API contract.
Is it going to make a difference if I move off the deprecated WorkspaceEdit api?
The issue you have mentioned with the editor service, I wonder if that could be in play here because this failure is just implying that the cell did not get rendered and initially request statusbar items. This test also doesn't make sense because it's just awaiting the same promise twice
Change:
}, { "name": "CSS ID", <del> "scope": "meta.selector.css entity.other.attribute-name.id", </del> <ins> "scope": "meta.selector entity.other.attribute-name.id", </ins> "settings": { "fontStyle": "", "foreground": "#9872A2"

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.86.0 OS Version: macOS 14.2.1 Steps to Reproduce: the Monokai Dimmed theme a .less file that the syntax higlighting colors are very different to the previous release This is what the less syntax highlighting looked like in v1.85.2 with the Monokai Dimmed theme enabled: ! And this is what it looks like in 1.86.0: ! The main problem is that property names are now the same color as property values that are keywords - e.g. , & - but it's also a bit annoying that LESS variables are no longer a uniform color. I've checked a few other color themes and they don't seem to have this problem. This is a bit of a guess but maybe Monokai Dimmed needs to be updated following the changes introduced in ?
Yes, agree, this needs an update here:
Change:
return priorityToRank(b.editorInfo.priority) - priorityToRank(a.editorInfo.priority); } }); <del> const contribGroups: { defaults: Array<IQuickPickSeparator | IQuickPickItem>, optional: Array<IQuickPickSeparator | IQuickPickItem> } = { defaults: [ { type: 'separator', label: localize('editorOverride.picker.default', 'Defaults') } ], optional: [ { type: 'separator', label: localize('editorOverride.picker.optional', 'Optional') } ], }; </del> <ins> const quickPickEntries: Array<IQuickPickItem | IQuickPickSeparator> = []; </ins> // Get the matching contribtuions and call resolve whether they're active for the picker contributionPoints.forEach(contribPoint => { const isActive = currentEditor ? contribPoint.editorInfo.describes(currentEditor) : false; <del> const quickPickEntry = { </del> <ins> const quickPickEntry: IQuickPickItem = { </ins> id: contribPoint.editorInfo.id, label: contribPoint.editorInfo.label, description: isActive ? localize('promptOpenWith.currentlyActive', "Currently Active") : undefined, detail: contribPoint.editorInfo.detail ?? contribPoint.editorInfo.priority, <del> buttons: alwaysUpdateSetting ? [] : [{ iconClass: Codicon.gear.classNames, tooltip: localize('promptOpenWith.setDefaultTooltip', "Set as default editor for '{0}' files", extname(resource)) }], </del> }; <del> if (contribPoint.editorInfo.priority === ContributedEditorPriority.option) { contribGroups.optional.push(quickPickEntry); } else { contribGroups.defaults.push(quickPickEntry); } </del> <ins> quickPickEntries.push(quickPickEntry); </ins> }); <del> return [...contribGroups.defaults, ...contribGroups.optional]; </del> <ins> if (!showDefaultPicker) { const separator: IQuickPickSeparator = { type: 'separator' }; quickPickEntries.push(separator); const configureDefaultEntry = { id: EditorOverrideService.configureDefaultID, label: localize('promptOpenWith.configureDefault', "Configure default editor....") }; quickPickEntries.push(configureDefaultEntry); } return quickPickEntries; </ins> } <del> private async doPickEditorOverride(editor: IEditorInput, options: IEditorOptions | undefined, group: IEditorGroup, alwaysUpdateSetting?: boolean): Promise<[IEditorOptions, IEditorGroup | undefined] | undefined> { </del> <ins> private async doPickEditorOverride(editor: IEditorInput, options: IEditorOptions | undefined, group: IEditorGroup, showDefaultPicker?: boolean): Promise<[IEditorOptions, IEditorGroup | undefined] | undefined> { </ins> type EditorOverridePick = { readonly item: IQuickPickItem;

Discussion:
When changing the default editor we show a in the quick pick to change this. The gear action by itself is not clear that it will immediately change the default and assume there would be another screen to confirm. ! Change the flow to match how you select different formatters to make it clearer/explicit. In the formatter case, there is a "Configure Default Formatter..." that is clear and indicates that user input is required on the next step. The same can be applied to default editors. ! cc
Change:
exclude: glob.IExpression; watcherExclude: { [filepattern: string]: boolean }; encoding: string; <ins> defaultLanguage: string; </ins> trimTrailingWhitespace: boolean; autoSave: string; autoSaveDelay: number;

Discussion:
VSCode Version: 1.2.1 OS Version: Windows 10 64x Steps to Reproduce: create new file, before save file with '.js' extension and the manual language selection, need to have option to default language e.g. JavaScript, not plaintext as default
We would need to introduce a workbench configuration such that there is a default language mode for new files opened. Such that it is being picked up before a user manuly chooses a mode or sets the file extension.
I would think this could also be done nicely from an extension.
This is one of my key uses from PowerShell ISE that is hard to convert over to VS Code. I use the Untitled page often to construct commands and scripts rather than doing it in terminal because its much easier to edit and I'm not wanting to save it just yet. The trick though is this is Visual Studio Code and versatile so sometimes I will want the default to be different based on the language I'm focusing on in a given period. The two ways to handle this would be: Command Line option to select default language on startup. File New --Language menu options The first option allows me to create a shortcut focused on my language. VS Code PowerShell and VS Code C#. It would also make it easier for extensions to configure the environment more for their use if they knew someone was starting it up as their language. The second option should not be defaults, but rather configurations for me to add my own list to the File menu. I like both approaches but if I had to choose one, the first I think could be more useful.
I just looked into making an extension for this but there doesn't seem to be an API to change the language ID of a TextDocument. I tried passing the language ID as a parameter to but it always displays the quick pick dialog. Any ideas?
I think this can be done via a new command using the new API:
That doesn't work for new files that the user creates using "File -New", "Files: New File" or double-clicking in the tab area. Though maybe I should just send a PR to VS Code to add an official setting for default language mode :)
Oh yeah, but I would start with an extension first to see how it works. You can easily map it to Ctrl+N for "New File" by default.

All in all, also not opposed to seeing a PR on this, e.g. could be something like editor.defaultLanguage or file.defaultMode.
maybe? Not sure that most users know what a "mode" is.
I'm going to work on this today!
Verify: a new setting allows to configure the default language mode a new untitled file should get you can still change the mode from the picker and the untitled file will keep this association even between restarts
Change:
.scm-view .button-container > .monaco-description-button { flex-direction: row; flex-wrap: wrap; <del> height: 30px; </del> padding: 0 4px; overflow: hidden; }

Discussion:
Using the Amethyst theme the label of the "Sync Changes" button is not vertically aligned: <img width="626" alt="image" src="https://user-"//cc
That‘s not an issue for me. The main issue for the "Sync Changes" button is that, it allways shows. It should be hidden when there is no changes to sync. !
that is unrelated to the problem that this issue is tracking. Also the problem that you are describing has already been fixed in the latest Insiders release, and it will be included in the next Stable release.
I think this is the same border issue except in the button we cap the height to so it forces everything to be shifted down by 1-2px: <img width="294" alt="CleanShot 2022-07-21 at 08 43 45 src="https://user-"If you remove the height then it looks better: <img width="234" alt="CleanShot 2022-07-21 at 08 46 01 src="https://user-"
thanks for looking into this. your analysis aligns with my findings. I will try to get a fix for this in next week.
Change:
this.setFullScreen(false); this.setFullScreen(true); } <ins> this.sendWhenReady('vscode:displayChanged'); </ins> }, 100)); const displayChangedListener = () => simpleFullScreenScheduler.schedule();

Discussion:
VSCode Version: 1.27.2 OS Version: Windows 10 Enterprise 1803 Build .345 Steps to Reproduce: Pre Condition: Dual monitor setup. Screen 1 on top of Screen 2. Screen 1 Scale set to 150% Screen 2 Scale set to 125% Visual studio code open with a python script on Screen 1. down some p-thon the cursor back a few char positions and make note. the vs code app from Screen 1 to Screen 2 where it resizes. the relocation of the cursor. your code and note that the cursor does not match the output text. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Unsure. Note: I am unsure if this is a Windows 10 bug or Visual Studio code bug but I have not noticed this on other software at the time of this bug report. In the meantime I have aligned my screen scaling as a work around for this issue.
This is caused by scaling difference. The bigger the scaling difference, the more evident. I have my surface book 2's main monitor set to 150% scaling, and my external monitor set to 100% scaling. Leaving VSCode open after the monitor switch will result in bad the cursor alignment. The workaround is to restart VSCode.

Version 1.19.3 Commit Date 2018-01-25T10:36:34.867Z Shell 1.7.9 Renderer 58.0.3029.110 Node 7.9.0 Architecture x64 Steps to Reproduce: VSCode using 4K monitors (150x magnify) the session remotely via RDP using 1080p monitors From now on, even if taking back the session locally, the caret position is corrupt. The picture shows the result of highlighting the "location" word. The caret has an offset of 4 characters to the right. ! Does this issue occur when all extensions are disabled?: Yes

Following the discussion in Repro steps on Windows: use a monospace font, make sure ligatures are not used, etc. (i.e. default editor related settings) change the scale setting of the display the editor decorations / selection should render correctly (on top of the correct text) (the problem was that the font measurements done with a certain display scale were used across all display scales).
Change:
getAgents(): IChatAgentData[]; getActivatedAgents(): Array<IChatAgent>; getAgentsByName(name: string): IChatAgentData[]; <ins> agentHasDupeName(id: string): boolean; </ins> /** * Get the default agent (only if activated)

Discussion:
I removed this to move over to using the agent, which required setting . Chatted with and I should add another agent to support the agent in both places, only making it the default for the terminal location. fyi
Verified that is available in panel chat.
Change:
const debugIconDisconnectColor = theme.getColor(debugIconDisconnectForeground); if (debugIconDisconnectColor) { <del> collector.addRule(`.monaco-workbench .part > .title > .title-actions .action-label${ThemeIcon.asCSSSelector(icons.debugDisconnect)},.monaco-workbench .debug-view-content ${ThemeIcon.asCSSSelector(icons.debugDisconnect)}, .monaco-workbench .debug-toolbar ${ThemeIcon.asCSSSelector(icons.debugDisconnect)} { color: ${debugIconDisconnectColor}; }`); </del> <ins> collector.addRule(`.monaco-workbench .part > .title > .title-actions .action-label${ThemeIcon.asCSSSelector(icons.debugDisconnect)},.monaco-workbench ${ThemeIcon.asCSSSelector(icons.debugDisconnect)} { color: ${debugIconDisconnectColor}; }`); </ins> } const debugIconRestartColor = theme.getColor(debugIconRestartForeground);

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.87.1 OS Version: Windows 11 Home .3235 Steps to Reproduce: "debug.toolBarLocation" to commandCenter, and adjust the "debugIcon.disconnectForeground" color value: seems to be the default color, vs "floating" or "docked" settings that display the correct color. This is also the case when set in a custom theme extension. Example screenshot of problem: !
Change:
import * as assert from 'assert'; <del> import { getSelectedChanges, applyChangesToModel } from 'vs/workbench/parts/git/common/stageRanges'; </del> <ins> import { SelectedChange, getSelectedChanges, applyChangesToModel, getChangeRevertEdits } from 'vs/workbench/parts/git/common/stageRanges'; </ins> import { Model } from 'vs/editor/common/model/model'; import { IChange } from 'vs/editor/common/editorCommon'; import { Selection } from 'vs/editor/common/core/selection';

Discussion:
There's probably already a feature request for this but I can't find it. I want to be able to select a change in the diff editor and revert it, same as how I can stage it. In SourceTree this is called "discard selected lines" although "revert" seems better, unless it's "discard selected changes". I'm working on a PR for this.
I think it is connected with
Change:
return new ExtHostOutputChannel(id, name, logger, this.proxy, extension); } <del> private async doCreateLogOutputChannel(name: string, logLevel: LogLevel, extension: IExtensionDescription): Promise<ExtHostLogOutputChannel> { </del> <ins> private async doCreateLogOutputChannel(name: string, logLevel: LogLevel | undefined, extension: IExtensionDescription): Promise<ExtHostLogOutputChannel> { </ins> const extensionLogDir = await this.createExtensionLogDirectory(extension); const file = this.extHostFileSystemInfo.extUri.joinPath(extensionLogDir, `${name.replace(/[/:*?"<>|]/g, '')}.log`); const logger = this.loggerService.createLogger(file, { name }, logLevel);

Discussion:
Testing I have two "onDidChangeLogLevel" listeners: one on "" and one on my channel and I'm setting the log levels with this action: ! In the test items description you said: log level change is being propagated in env and also in your log output channel For me only the listener on "" fires.
Change:
} } <ins> public expandUnresolved(): void { for (const widget of this._commentWidgets) { if (widget.commentThread.state === languages.CommentThreadState.Unresolved) { widget.expand(); } } } </ins> public nextCommentThread(): void { this._findNearestCommentThread(); }

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:
if (filePaths.length === 0) { // nothing left <del> return Promise.resolve(new Set<string>()); </del> <ins> return resolve(new Set<string>()); </ins> } // https://git-scm.com/docs/git-check-ignore#git-check-ignore--z

Discussion:
While working and testing PR for issue (warning for unsaved files before commit), I encountered what I think are two bugs. The first I was able to identify and fix as far as I can tell. I am no Typescript expert so maybe I am off-base. Second issue not so sure about, seems to return an extra set entry that is empty. Have to investigate this one further. NOTE: could this be related to ? For first issue: If there are no resulting filePaths entries, an empty set should be returned via Promise. The code seems to return a promise within a promise which gets lost. I presumed should be resolve(new Set<string()); NOT: Promise.resolve(new Set<string()); checkIgnore(filePaths: string[]): Promise<Set<string{ return (Operation.CheckIgnore, () ={ return new Promise<Set<string((resolve, reject) ={ filePaths = (filePath =!path.relative(, filePath).startsWith('..')); if ( === 0) { // nothing left Nested Promise return Promise.resolve(new Set<string()); } // https://git- const child = (['check-ignore', '-z', '--stdin'], { stdio: [null, null, null] }); (('0'), 'utf8'); const onExit = (exitCode: number) ={ if (exitCode === 1) { // nothing ignored resolve(new Set<string()); } else if (exitCode === 0) { // paths are separated by the null-character resolve(new Set<string(('0'))); } else { reject(new GitError({ stdout: data, stderr, exitCode })); } }; Fixed with PR
Nice find.
Adding -label for consideration
Great catch! I actually reviewed this code and didn't catch this.
Not the first time that I am wishing for a lint rule which checks all code paths inside a promise initialiser...
I have cherry-picked this change for the 1.18.1 release
Thanks guys !
Change:
} private _runBuildCommand(): void { <ins> if (!this._tasksReconnected) { return; } </ins> return this._runTaskGroupCommand(TaskGroup.Build, { fetching: nls.localize('TaskService.fetchingBuildTasks', 'Fetching build tasks...'), select: nls.localize('TaskService.pickBuildTask', 'Select the build task to run'),

Discussion:
Testing default build task in VS Code repo running (I also installed the Java extension pack like in ) window Ctrl+Shift+B a few times :bug: get two sets of default build tasks. They are both reconnected, if I edit a file and hit save, both sets of tasks display log updates !
Duplicate