jiebi/CodeConvo huggingface dataset:
Change:
this.termFilterState = {}; this.globList = []; <del> this.onlyTags.clear(); </del> <ins> this.includeTags.clear(); this.excludeTags.clear(); </ins> let globText = ''; let lastIndex = 0;

Discussion:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --Splitting this out from In the Test UI you can filter by text or exclude text using and filter by a . It would be nice if we could also negate tags in the filter like to exclude a specific tag. <!-- Describe the feature you'd like. --
Starting point, this is where tag filtering happens:
Change:
import { IActionViewItem } from '../../../../base/browser/ui/actionbar/actionbar.js'; import { IDropdownMenuActionViewItemOptions } from '../../../../base/browser/ui/dropdown/dropdownActionViewItem.js'; import { ActionViewItem } from '../../../../base/browser/ui/actionbar/actionViewItems.js'; <del> import { renderLabelWithIcons } from '../../../../base/browser/ui/iconLabel/iconLabels.js'; </del> import { IQuickInputService, IQuickPickItem, IQuickPickSeparator } from '../../../../platform/quickinput/common/quickInput.js'; import { Event } from '../../../../base/common/event.js'; import { Iterable } from '../../../../base/common/iterator.js';

Discussion:
Type: <bBug</b! I expected an upstream/main badge on the tree, and that badge on the hover tip to have a colour. 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
Nice catch! Fix should be in tomorrow's Insiders release.
Change:
this.panelService.openPanel(debug.REPL_ID, false).done(undefined, errors.onUnexpectedError); } <del> const openDebugOptions = this.configurationService.getValue<debug.IDebugConfiguration>('debug').openDebug; </del> <ins> this.openDebugOptions = this.configurationService.getValue<debug.IDebugConfiguration>('debug').openDebug; </ins> // Open debug viewlet based on the visibility of the side bar and openDebug setting <del> if (openDebugOptions === 'openOnSessionStart' || (openDebugOptions === 'openOnFirstSessionStart' && this.firstSessionStart)) { </del> <ins> if (this.openDebugOptions === 'openOnSessionStart' || (this.openDebugOptions === 'openOnFirstSessionStart' && this.firstSessionStart)) { </ins> this.viewletService.openViewlet(debug.VIEWLET_ID); } this.firstSessionStart = false;

Discussion:
Currently if I start my App with another View than Debug View open and the debugger breaks because of a break point or an exception I have to manually switch to the debug view. It would be incredible if I could set an option to display the debug view in that cases automatically Thanks for your great Work!
This is a fair feature request. If we get more users asksing for this we would be willing to accept a PR that fixes this. Thanks
Why only as PR? I guess it will be only a very small change but I'm not a Typescript dev and have no idea about the internal structure of VS Code. For your team this should be a quick fix.
Because we encourage people to be invovled in our open source project Code pointer The following setting should be updated to also cover this case  to also have the following option "openOnDebugBreak" No typescript knowledge is needed for this PR fyi
Change:
import { ResolvedKeybinding } from 'vs/base/common/keybindings'; import { URI } from 'vs/base/common/uri'; import { IRange } from 'vs/editor/common/core/range'; <ins> import { IEditorContribution } from 'vs/editor/common/editorCommon'; </ins> import { ITextModel } from 'vs/editor/common/model'; import { ConfigurationTarget } from 'vs/platform/configuration/common/configuration'; import { ConfigurationScope, EditPresentationTypes, IExtensionInfo } from 'vs/platform/configuration/common/configurationRegistry';

Discussion:
With there is a new -menu which a big blue buttons. This is used in the merge editor and to hint to open the merge editor. This new menu should be used for: [x] [ ] ~~ / [x] [ ]
Other potential adoptors [ ] [ ] [ ] [ ]
Digging into it, I don't think can be adopted for the diff editor, as the button should be for both editors, not only the right side ( is a , but is ).
Change:
detail?: string; /** <ins> * Show this item always */ shouldAlwaysShow?: boolean; /** </ins> * Optional flag indicating if this item is picked initially. * (Only honored when the picker allows multiple selections.) *

Discussion:
Problem The time you search for the branch and not find any, there are no other options to proceed. <img width="682" alt="screen shot 2018-09-15 at 11 06 09" src="https://user-"I as a developer would need to delete the search and then click on "create a new branch". Solution Keep "create a new branch" option always. <img width="656" alt="screen shot 2018-09-15 at 11 22 56" src="https://user-"
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.617 --- <!-- score: 0.587 --- <!-- score: 0.552 --- <!-- score: 0.547 --- <!-- score: 0.529 --<!-- potentialduplicatescomment --
Is this supported from an extension? Eg: keep an option always visible.
Dang, just noticed that you already submitted a PR to address this. Closed my PR, feel free to grab the integration test I if you want
since my PR is merged already, feel free to create a PR with tests :)
I a PR to add tests and also fix a small bug (when explicitly settings items on a the field was not properly propagated). Additional thoughts I had (should open another issue for discussion?): In my opinion, items that should always be shown shouldn't display search highlights. The highlights are possibly redundant and IMO it would look more elegant without I feel like after accepting the option, the input text should be preserved. Would a PR to address this be accepted? Also, possibly should this behavior be exposed for user control? (i.e. similarly to a field, a field.)
:+1: Nah, sounds like a very good default value.
Change:
"textCodeBlock.background": "#6e768166", "textLink.activeForeground": "#40A6FF", "textLink.foreground": "#40A6FF", <del> "textPreformat.foreground": "#f85149", </del> "textSeparator.foreground": "#21262d", "titleBar.activeBackground": "#181818", "titleBar.activeForeground": "#cccccc",

Discussion:
In the experimental dark theme the vscode-textPreformat-foreground token color shows up as red for me: !
Change:
const fs = require('fs'); const cp = require('child_process'); const yarnVersion = cp.execSync('yarn -v', { encoding: 'utf8' }).trim(); <del> const parsedYarnVersion = /^(d+).(d+)./.exec(yarnVersion); </del> <ins> const parsedYarnVersion = /^(d+).(d+).(d+)/.exec(yarnVersion); </ins> const majorYarnVersion = parseInt(parsedYarnVersion[1]); const minorYarnVersion = parseInt(parsedYarnVersion[2]); <del> if (majorYarnVersion < 1 || minorYarnVersion < 10) { console.error('033[1;31m*** Please use yarn >=1.10.1.033[0;0m'); </del> <ins> const patchYarnVersion = parseInt(parsedYarnVersion[3]); if ( majorYarnVersion < 1 || majorYarnVersion === 1 && ( minorYarnVersion < 10 || (minorYarnVersion === 10 && patchYarnVersion < 1) ) || majorYarnVersion >= 2 ) { console.error('033[1;31m*** Please use yarn >=1.10.1 and <2.033[0;0m'); </ins> err = 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?: n/a <!-- 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: (currently at ) OS Version: n/a Steps to Reproduce: the existing code in and turn it into a function that accepts a parameter: that function in , e.g. using . should error, but don't: - According to the error on , requires =1.10.1, but is only enforcing = 1 or = x.10. Granted, there is no yarn v3.10 yet, but there may be someday. And if it actually requires =1.10.1 (and not just =1.10.0) as the error states, it should enforce that as well.
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.71.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Related docs change:
Change:
entryId, name: item.entry.name, text: item.entry.text, <del> command: typeof item.entry.command === 'string' ? item.entry.command : undefined, </del> <ins> command: typeof item.entry.command === 'string' ? item.entry.command : typeof item.entry.command === 'object' ? item.entry.command.id : undefined, </ins> priority: item.priority, alignLeft: item.alignment === StatusbarAlignment.LEFT };

Discussion:
Testing I might be doing something wrong, my contribution: I see no status entry that I can click on. I also tried with an existing command such as . ! Extension code is a hello world: Full :
not implemented
Change:
git = ext!.exports.getAPI(1); if (git.repositories.length === 0) { <del> await eventToPromise(git.onDidOpenRepository); </del> <ins> const onDidOpenRepository = eventToPromise(git.onDidOpenRepository); await commands.executeCommand('git.openRepository', cwd); await onDidOpenRepository; </ins> } assert.strictEqual(git.repositories.length, 1);

Discussion:
These steps sometimes fail to succeed: Specifically the line: Since we first create all the files and then activate git, a repository should eventually open.
Given that you have seen this locally and/or seen it in CI, what's the workbench state when this happens? Specifically, a screenshot would be awesome.
Oh this isn't Playright. It's the git smoke tests. Which are extension tests.
is an interesting one because I see no error message from Parcel.
Change:
return label; } <del> private onBlur(): void { </del> <ins> private onCancel(): void { </ins> this._chords = null; this.hide(); } <del> private onEscape(): void { if (this._chords !== null) { </del> <ins> private clearOrHide(): void { if (this._chords === null) { this.hide(); } else { </ins> this._chords = null; <ins> this._keybindingInputWidget.clear(); </ins> dom.clearNode(this._outputNode); dom.clearNode(this._showExistingKeybindingsNode); <del> return; </del> } <del> this.hide(); </del> } private hide(): void {

Discussion:
Type: <bBug</bPreviously pressing escape while "Record Keys" was active in the keybindings UI would disable key recording and leave the search query intact. Now it disables key recording and clears the search query which makes it much harder to use. I traced this regression to 1.78. I'm guessing this is an issue with keybindings. The binding for is being processed in addition to the (hard-coded?) binding to stop recording. ! VS Code version: Code - Insiders 1.79.0-insider (, 2023-05-04T22:11:08.187Z) 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 --
Change:
}, "dependencies": { "applicationinsights": "1.0.8", <del> "chokidar": "3.4.3", </del> <ins> "chokidar": "3.5.0", </ins> "graceful-fs": "4.2.3", "http-proxy-agent": "^2.1.0", "https-proxy-agent": "^2.2.3",

Discussion:
Steps to Reproduce: on Apple SI a folder in devtools:
Related failing unit test:
Chokidar v3.5.0 was just released that takes in fsevents universal build , we can update to it.
yep this required compiling fsevents as universal binary
Change:
if (to === this.location) { this.onDidRegisterViewContainers([container]); <ins> // Open view container if part is visible and there is no other view container opened const visibleComposites = this.compositeBar.getVisibleComposites(); if (!this.paneCompositePart.getActivePaneComposite() && this.layoutService.isVisible(this.paneCompositePart.partId) && visibleComposites.length) { this.paneCompositePart.openPaneComposite(visibleComposites[0].id); } </ins> } }

Discussion:
Testing When I dragged one of the icons to the second side bar, I wanted it to be placed before the other icon, however, it was placed behind it even though the bar indicating where it would be placed was in front of the icon. Also I noticed it's not possible to drop an icon on the top part of the side bar when the side bar is empty. It's only possible to drop it on the view part of the side bar. I think it should be possible to drop it everywhere in the second side bar when it is empty. !
I cannot reproduce this. I see it is happening in the recording, but it would be great if you can give me steps you followed to repro. Agreed. This is not new and has been like this before. But, I observed another bug in your recording that dropping the view container is not activating it - this used to be getting activated in older versions. Fixed that.
Change:
constructor( @ISCMService private readonly _scmService: ISCMService, <ins> @IActivityService private readonly _activityService: IActivityService, </ins> ) { }

Discussion:
open a multifile diff reload window while the diff editor stores and loads it says that there are no changes yet <img width="1178" alt="Screenshot 2024-06-21 at 09 16 43" src=""
Thanks for filing! Briefly looked into it, but fixing it is a little bit more complex than I thought. The model creation is what takes a while, and during that time the multi file diff editor just has no model. It would be better if the model creation is immediate, but it has some property, that the editor could then show.
Change:
return await this.run(Operation.RevList, () => this.repository.getCommitCount(range)); } <ins> async revParse(ref: string): Promise<string | undefined> { return await this.run(Operation.RevParse, () => this.repository.revParse(ref)); } </ins> async reset(treeish: string, hard?: boolean): Promise<void> { await this.run(Operation.Reset, () => this.repository.reset(treeish, hard)); }

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: OS Version: Steps to Reproduce: on a file from the "All Changes" node that the diff editor does not have the commit for the right hand side !
Change:
const editorModel = editor?.getModel(); const editorUri = editorModel?.uri; const existingId = editorModel?.getLanguageId(); <del> const enablementConfig = this._configurationService.getValue('workbench.editor.languageDetectionHints'); const enabled = enablementConfig === 'always' || enablementConfig === 'textEditors'; </del> <ins> const enablementConfig = this._configurationService.getValue<LanguageDetectionHintConfig>('workbench.editor.languageDetectionHints'); const enabled = typeof enablementConfig === 'object' && enablementConfig?.untitledEditors; </ins> const disableLightbulb = !enabled || editorUri?.scheme !== Schemas.untitled || !existingId; if (disableLightbulb || !editorUri) {

Discussion:
The candidate fix for was to just disable language detection in notebooks by default. With a bit more time to work on it, a better solution should be derived.
is this fix insider released?
is it now :)
Change:
private static ID: number = 0; <ins> public suppressMouseDown: boolean; </ins> private _id: string; private _domNode: HTMLElement;

Discussion:
VSCode Version: Version 1.3.0-insider (1.3.0-insider) OS Version: OS X El Capitan 10.11.5 Steps to Reproduce: on the non-link area of a code lens line that nothing at all happens Would really like it to at a minimum to focus the editor (if not already focused), but we really love it if it move the cursor to the previous line. I find myself VERY often clicking on that area to start typing above it and nothing happens.
I'm assuming (maybe) that this wouldn't be a difficult change -- so if someone had the time to point me in the vague direction, I would be happy to attempt to open a PR for this. :)
PR welcome! :) It is in I would extract the code that does the focus: to a closure called inside the method. Then, at you can call and then : The reason focusing is complicated is because IE has some weirdness around redirecting focus when coming from the URL bar and doing a mouse down. And the already is a good indicator that the view zone does not want to handle mouse events.
Change:
import { attachSelectBoxStyler } from 'vs/platform/theme/common/styler'; import { IThemeService } from 'vs/platform/theme/common/themeService'; import { IQuickOpenService } from 'vs/platform/quickOpen/common/quickOpen'; <ins> import { ActionBarContributor } from 'vs/workbench/browser/actions'; import { TerminalEntry } from 'vs/workbench/parts/terminal/browser/terminalQuickOpen'; import { IInstantiationService } from 'vs/platform/instantiation/common/instantiation'; export const TERMINAL_PICKER_PREFIX = 'term '; </ins> export class ToggleTerminalAction extends TogglePanelAction {

Discussion:
Needs one for some keybindings
Also should add a rename terminal button to each entry for easy discoverability
Change:
__vsc_preexec() { __vsc_initialized=1 if [[ ! "$BASH_COMMAND" =~ ^__vsc_prompt* ]]; then <del> __vsc_current_command=$BASH_COMMAND </del> <ins> # Use history if it's available to verify the command as BASH_COMMAND comes in with aliases # resolved if [ "$__vsc_history_verify" = "1" ]; then __vsc_current_command="$(builtin history 1 | sed -r 's/ *[0-9]+ +//')" else __vsc_current_command=$BASH_COMMAND fi </ins> else __vsc_current_command="" fi

Discussion:
Testing In Remote-WSL + bash + subshell, if I run and then use the command decoration to rerun the command, it instead runs . !
This is also the reason may be replaced by ; we're sending the alias resolved command line instead of the raw command line as input.
We should also verify this doesn't happen with aliases in zsh
fyi verifier, reproduces in normal in a non-subshell
to reproduce: in a terminal to see the ones you've defined the part to the left of the command decoration menu, the command's alias (part to the right of ) is the input
it does not
the alias value is also displayed in the quickpick atm
I thought of an even better idea to what we talked about, we could use the old history method to supplement our current better method; if there are no problematic histcontrol settings and the latest history command changed between precious and now, assume it was an alias and use that?
could you verify this one when you get a chance?
still seems to repro in Remote-WSL ! Version: 1.71.0-insider (user setup) Commit: Date: 2022-08-23T10:56:12.685Z Electron: 19.0.12 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes
Does show anything? My Ubuntu wsl shows in which case we cannot use that history method which is a known edge case that I don't think we can handle currently and is not worth tracking imo.
Yeah the output is . Is there a value I can change that to which would allow me to verify the fix?
it can be set to the empty string or - set this in your which should run before shell integration
<img width="278" alt="image" src="https://user-"

See comments in Workaround for anyone hitting this is to set to one of , , in your .
See earlier report on
/duplicate
Change:
} })); <del> this._subscriptions.add(domEvent(document.body, 'keyup', true)(e => { </del> <ins> this._subscriptions.add(domEvent(window, 'keyup', true)(e => { </ins> if (!e.altKey && this._keyStatus.altKey) { this._keyStatus.lastKeyReleased = 'alt'; } else if (!e.ctrlKey && this._keyStatus.ctrlKey) {

Discussion:
Issue Type: <bBug</bRelease Notes alt to open the file menu menu dosn't opens. menu opens, focus moves VS Code version: Code - Insiders 1.48.0-insider (, 2020-08-07T11:32:09.993Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (22)</summaryExtensionVersion ------ github-markdown-preview0.0.2 markdown-checkbox0.1.3 markdown-emoji0.0.9 markdown-preview-github-styles0.1.6 markdown-yaml-preamble0.0.4 vscode-astyle0.9.0 vscode-markdownlint0.36.2 githistory0.6.9 EditorConfig0.15.1 vscode-pull-request-github0.18.1 vscode-language-pack-ru1.48.2 python2020.7. remote-ssh0.51.0 remote-ssh-edit0.51.0 remote-wsl0.44.4 cmake-tools1.4.1 cpptools0.29.0 vsliveshare1.0.2478 vsliveshare-audio0.1.85 vsliveshare-pack0.4.0 code-spell-checker1.9.0 code-spell-checker-russian0.2.4 </details<!-- generated by issue reporter --
I can reproduce this - just open any markdown preview and will not open the file menu. I think we should fix this for this release, as it is a breaking change (in last stable I can nicely press to open the file menu). Due to that I am assigning this to July and can move it out if he would prefer to fix it next milestone Also fyi for custom menus
Has the way the menus handle mnemonics changed this iteration? The webview still seem to be dispatching the events but they aren't being handled by anyone
nope no changes that i know of
should be handled here
is working for me and in insiders on windows.

For just pressing to show the mnemonics, this does not seem like a regression from 1.47 in my testing but it was working in 1.46
I was just testing this out, I see no new behavioral differences between now and 1.46 does not focus the custom menubar with release notes focused. We do not get the alt event +<mnemonicdoes open the resepective menu with release notes focused.
hay can we fix that? because it's really strange in my opinion.
Changing the listeners from using to fixes the initial trigger, but keys like don't clear the focus. Moving out to look into a better fix
is there something webviews need to do to have keys passed back to VS Code? This came up at and I can repro in both stable and insiders. The webview hosts an iframe if that matters. I'm unable to interact with VS Code (eg. to open command palette) when focus is in the web view. I tried loading a non-Flutter page in there to check it wasn't specific to Flutter, but it's happening with other pages too.
If you can avoid it, don't use an iframe. If you absolutely must use an iframe, then you need to dispatch the keypresses back to webviews. See
I don't think there's any way to avoid the iframe really. The linked solution didn't work due to CORS issues, but the comments further down using postMessage to bounce the events over does. I'll see whether we can get something like that in the embedded app. Thanks!