jiebi/CodeConvo huggingface dataset:
Change:
height: 100%; background-repeat: no-repeat; background-position: 50% 50%; <del> margin-right: 8px; </del> <ins> margin-left: 5px; </ins> } .scm-view .monaco-list-row .resource > .decoration-icon.codicon {

Discussion:
After has been fixed by add . Now it's offset to the left by 8px. ! <!-- 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.2 OS Version: Win10 20H2 Steps to Reproduce: SVN and the SVN extension svn co to checkout that repository the release-notes folder in VS Code some changes
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.87.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
thank you very much for reporting this issue. You can reproduce this issue with the extension as well if you disable the setting and reload the window. I will look at this and will push a fix later this week.
Change:
// create a new strategy switch (session.editMode) { <del> case EditMode.Live: this._strategy = this._instaService.createInstance(LiveStrategy, session, this._editor, this._zone.value); break; </del> case EditMode.Preview: this._strategy = this._instaService.createInstance(PreviewStrategy, session, this._editor, this._zone.value); break; case EditMode.LivePreview: <del> default: </del> this._strategy = this._instaService.createInstance(LivePreviewStrategy, session, this._editor, this._zone.value); break; <ins> case EditMode.Live: default: this._strategy = this._instaService.createInstance(LiveStrategy, session, this._editor, this._zone.value); break; </ins> } this._session = session;

Discussion:
We believe is better than livePreview and therefore the default should change. Also we want to retire livePreview gracefully, e.g remove the option and then the implementation
Verify that defaults to
Change:
export const logLevel: LogLevel; /** <del> * The detected default shell for the extension host, this is overridden by the * `terminal.integrated.shell` setting for the extension host's platform. */ export const shell: string; /** </del> * An [event](#Event) that fires when the log level has changed. */ export const onDidChangeLogLevel: Event<LogLevel>;

Discussion:
Provided the Python extension uses the API and it works as expected (), we should finalize it in July.
To verify just do a quick test that it seems to be working as expected on any platform, a more thorough test was done in the June milestone.
Change:
const sourceAction = new SourceAction(action, notebook, isPrimary); const stateChangeListener = sourceAction.onDidChangeState(() => { this._onDidChangeSourceActions.fire({ <del> notebook: notebook.uri </del> <ins> notebook: notebook.uri, viewType: notebook.viewType, </ins> }); }); sourceActions.push([sourceAction, stateChangeListener]);

Discussion:
When we only have a couple of notebook controllers created for a notebook type, without any kernel detection task or kernel source commands, the "Select Another Kernel" should not show.
I have no kernels in the MRU, clicking Select Kernel brings me to this quickpick, and clicking the back button here does nothing--I think it shouldn't be shown in this scenario ! I have the Jupyter extension installed but not the Python extension installed, with the MRU picker enabled, the Select Kernel dropdown spins forever like this: !
Change:
const delegate: IActionListDelegate<CodeActionItem> = { onSelect: async (action: CodeActionItem, preview?: boolean) => { <del> try { await this._applyCodeAction(action, /* retrigger */ true, !!preview, ApplyCodeActionReason.FromCodeActions); } finally { actions.dispose(); } </del> <ins> this._applyCodeAction(action, /* retrigger */ true, !!preview, ApplyCodeActionReason.FromCodeActions); </ins> this._actionWidgetService.hide(); currentDecorations.clear(); },

Discussion:
Type: <bBug</bI'm not completely sure if this is caused by VSCode or Rust-Analyzer but I think it's VSCode. Whenever I try to open the imports menu from quick fixes, it instantly closes. It should wait for me to pick an import. This feature broke sometime within the last couple weeks. VS Code version: Code - Insiders 1.87.0-insider (Universal) (, 2024-02-16T16:39:24.006Z) OS version: Darwin arm64 23.2.0 Modes: Remote OS version: Linux x64 6.7.4-arch1-1 <details<summarySystem Info</summary </details<details<summaryExtensions (11)</summaryExtensionVersion ------ better-comments3.0.2 vscode-nginx-conf0.3.2 postcss1.0.9 codespaces1.16.10 fluent-icons0.0.18 dotenv1.0.1 jupyter-keymap1.1.2 remote-ssh0.109. remote-ssh-edit0.86.0 remote-explorer0.5. rust-analyzer0.3.1839 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
tyler did some bisecting to one of my PRs, could be related. im assuming this quick fix is supposed to open a quick pick?
Yes it is.
Change:
// border: defaults to active background colors.registerColor( 'titleMenu.border', <del> { dark: activeBackground, hcDark: activeBackground, light: activeBackground, hcLight: activeBackground }, </del> <ins> { dark: activeBackground, hcDark: colors.inputBorder, light: activeBackground, hcLight: colors.inputBorder }, </ins> localize('titleMenu-border', "Border color of the title menu"), false );

Discussion:
Looking at . Seems like it works fine on all the other themes I have installed. I think the theme tokens ultimately inherit from a null value here: <img width="535" alt="CleanShot 2022-05-13 at 08 31 49 src="https://user-"<img width="567" alt="CleanShot 2022-05-13 at 08 31 56 src="https://user-"
Can you help me to define colors for this?
I think makes the most sense here. <img width="665" alt="CleanShot 2022-05-16 at 08 13 18 src="https://user-"<img width="687" alt="CleanShot 2022-05-16 at 08 13 25 src="https://user-"I'll file a separate issue for this nested contrast border issue on hover: <img width="100" alt="CleanShot 2022-05-16 at 08 14 11 src="https://user-"
Nice catch - squeezed that into
Change:
private messagesVisibleContext: IContextKey<boolean>; private editorsVisibleContext: IContextKey<boolean>; private inZenMode: IContextKey<boolean>; <ins> private sideBarVisibleContext: IContextKey<boolean>; </ins> private hasFilesToCreateOpenOrDiff: boolean; private fontAliasing: string; private zenMode: {

Discussion:
Currently there is no way to tell if sidebar is visible. You can get the state only for 2/5 viewlets. Explorer: Search: Source Control: Debug: Extensions: Sidebar (any of the above is visible):
PR that fixes this is welcome. Code pointer Basicaly the part service would need to add new context key and set it when sidebar gets shown / hidden. I propose to call this context key .
Change:
private debugState!: IContextKey<string>; private inDebugMode!: IContextKey<boolean>; private debugUx!: IContextKey<string>; <ins> private debugSessionStarted!: IContextKey<boolean>; </ins> private breakpointsExist!: IContextKey<boolean>; private disassemblyViewFocus!: IContextKey<boolean>; private breakpointsToSendOnResourceSaved: Set<URI>;

Discussion:
Not sure it was always like this before, but look at this. Unless I set at least one breakpoint, it's not possible to show the "Breakpoints view" in the panel. Then its the only solution to toggle (All/Uncaught Exceptions). Was not possible to show this view without any user predefined breakpoints ? ! Flutter 3.3.7 • channel stable • Framework • revision (il y a 3 semaines) • 2022-11-01 16:59:00 -0700 Engine • revision Tools • Dart 2.18.4 • DevTools 2.15.0 Vscode: 1.73.1 OS: Linux Mint 20.3 x86_64 Kenel 5.15.0-53-generic
Not sure about this- did you move the breakpoints view into the test view? Does it work in the debug viewlet?
Not sure what you mean. Maybe larger screens captures will help. Do you see the "debug viewlet <= if it's so called" is not accessible in the menu when no breakpoint is defined ! But when is set one breakpoint, it appears in the menu & the viewlet also ! But this means that if you want to switch theses checkboxes : ! must need to define at least a breakpoint !! Is this not 2 extras click ? 1) turn on a dummy a breakpoint <===== ??? 2) switch the desired type of exception 3) turn off the dummy breakpoint <===== ???
Side note... It appears that the problem was in my current Flutter project but not now ...opening another one. I briefly checked if its a matter of doesn't seem to be. Would it be because of one dependency ?
How strange is this...I show you side by side On the left : freshly made project "test" =Debug viewlet not accessible in the right-click menu path is : On the right: an old project : =Debug viewlet is accessible in the right-click menu path is: !
I see, this happens when you don't have a in your project. Since it's possible to debug without defining a , we should show this view when you have started the debugger once previously.

If anyone wants to work on this, we should add a new context key that is set to true when a debug session starts, and when that context key is true, the breakpoints view should be visible:
I've submit a patch with a possible fix, let me know if it works.
I see the breakpoints view in a folder without a , but it has no contents when expanded, is that expected? <img width="583" alt="image" src="https://user-"Also, not sure if this is an intentional behavior change, but clicking Run and Debug in Insiders in the above scenario does nothing, while in Stable I get this quickpick <img width="791" alt="image" src="https://user-"I have Python extension v2023.1. in stable and v2023.1. in insiders, in case this is caused by an extension and not core.
Good catch, filed , thanks
Change:
options.fillExtraContextMenuActions(actions, e); this.fillContextMenuActions(actions, e); } <del> }, part, paneCompositePart, instantiationService, storageService, extensionService, viewDescriptorService, contextKeyService, environmentService); </del> <ins> }, part, paneCompositePart, instantiationService, storageService, extensionService, viewDescriptorService, contextKeyService, environmentService, layoutService); </ins> if (showGlobalActivities) { this.globalCompositeBar = this._register(instantiationService.createInstance(GlobalCompositeBar, () => this.getContextMenuActions(), (theme: IColorTheme) => this.options.colors(theme), this.options.activityHoverOptions));

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:
}); }); <del> // https://github.com/microsoft/vscode/issues/119826 suite.skip('environmentVariableCollection', () => { </del> <ins> suite('environmentVariableCollection', () => { </ins> test('should have collection variables apply to terminals immediately after setting', (done) => { // Text to match on before passing the test const expectedText = [

Discussion:
skipped in
Seems to only flake on Windows
Couldn't reproduce locally
Let's try re-enable in debt week
Change:
padding: 0 10px 10px; } <ins> .simple-find-part .monaco-inputbox > .ibwrapper > input { text-overflow: clip; } </ins> .monaco-workbench .simple-find-part { visibility: hidden;		/* Use visibility to maintain flex layout while hidden otherwise interferes with transition */ z-index: 10;

Discussion:
And instead pass in (or don't) a new option for the type
so the complexity here is that we can't reference the keybinding service within the super call to the constructor and need to do that to provide the options to the find input object that's read only.
the alternative would be to pass in the options from both the terminal view and terminal editor (redundant)
going to pass in an options object and handle the keybinding in simple find widget
Spent awhile on this, don't think we will get to it
Change:
dark: Color.fromHex('#808080').transparent(0.35), light: Color.fromHex('#808080').transparent(0.35), hc: contrastBorder <del> }, nls.localize('notebook.cellToolbarSeparator', "The color of the seperator in the cell bottom toolbar")); </del> <ins> }, nls.localize('notebook.cellToolbarSeparator', "The color of the separator in the cell bottom toolbar")); </ins> export const focusedCellBackground = registerColor('notebook.focusedCellBackground', { dark: transparent(PANEL_BORDER, .4),

Discussion:
nls.localize() generally involves human visible output. Technically there are 2-3 arguments and the main human facing one is the second. The first argument is often treated as an "opaque" string, but in most systems, it's used to communicate to localizers, so, to some extent, there is value in not having misspellings there either. I can split out the identifiers if requested... Does this issue occur when all extensions are disabled?: Yes
can you provide me with more details about this. We use Transifex to translate our strings and the system contains both the value and the key.
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Change:
return; } const contr = TerminalChatController.activeChatWidget || TerminalChatController.get(activeInstance); <del> contr?.chatWidget?.focusResponse(); </del> <ins> contr?.chatWidget?.inlineChatWidget.chatWidget.focusLastMessage(); </ins> } });

Discussion:
Note that both of these scenarios used to work. In the terminal inine chat, run a command like which yields just a chat message response. Try to tab to it. one cannot Run a command like which yields a code block response. Try to use to go from the input box to a code block response and vice versa. one cannot
Note that the keybindings are important because it's annoying as a SR /keyboard only user to have to tab through a bunch of things to reach the response.
This works for me, I do the following with success cmd+i, paste , press Enter wait for the response press tab repeatedly and reach the response
the tabbing part works for me in today's insider's
I'm able to spam Ctrl+Up on Windows to focus between the inputbox and the chat response, but I'm not able to spam Ctrl+Down to do the same. I'm unable to use either shortcut to focus from the inputbox directly into a code block within the chat response. Let me know if the behaviour is as expected or if there's some other steps I can follow.
I haven't tried windows yet. This won't directly focus the code editor, just the response.
this works on mac, could you pls try on windows?
The behavior seems wrong now and is quite disorienting: Input: ctrl+up will focus the response list ctrl+down will focus the response list Response list: ctrl+up does nothing ctrl+down does nothing Response code block: ctrl+up focuses the input ctrl+down focuses the response list I would expect: Input: ctrl+up does nothing ctrl+down will focus the response code block Response list: ctrl+up focuses the input Not sure? Response code block: ctrl+up focuses the input ctrl+down focuses the next code block, otherwise not sure
This issue was about cmdCtrl+up/down going between the response list and the input. This is unexpected, but unlikely to be attempted by the user IMO. Input: ctrlCmd+up will focus the response list This works on mac. Not sure why it doesn't on windows. Response list: ctrlCmd+up does nothing I didn't implement this yet, but can in April. Response code block: ctrl+up focuses the input ctrl+down focuses the response list
verified that this does work. I'm making a new issue about focusing the code block(s) and the bug with in the input focusing the list
Change:
this.setFullScreen(true); } <del> if (!this._win.isVisible()) { </del> <ins> if ( !this._win.isVisible() || // TODO@electron: Required condition ever since https://github.com/electron/electron/pull/33536 // landed in Electron 17.4.2: calling `window.maximize()` on macOS will wrongly result in // `window.isVisible()` to return `true` even though a different window might still be on top. // As such, we also need to ask for `window.isFocused()` which on macOS will ask whether the // window is a "key" window. (isMacintosh && !this._win.isFocused()) ) { </ins> this._win.show(); // to reduce flicker from the default window size to maximize, we only show after maximize } mark('code/didMaximizeCodeWindow');

Discussion:
Issue Type: <bBug</brun in the terminal where is the path to an existing directory see VSCode open the workspace as expected run in the terminal where is the path to an existing directory focus changes back to VSCode, but showing the window for project instead of project Here is a movie of the experience: ! In previous versions of VSCode, when opening a new project with , the new window would show up above any existing windows. This is what I expected to happen. VS Code version: Code 1.67.1 (, 2022-05-06T12:37:14.619Z) OS version: Darwin arm64 20.6.0 Restricted Mode: No <details<summarySystem Info</summary </details<details<summaryExtensions (17)</summaryExtensionVersion ------ vscode-tailwindcss0.8.3 vscode-eslint2.2.2 copilot1.19.5865 go0.33.0 terraform2.22.0 vscode-env0.1.0 jsonnet-language1.0.0 vscode-docker1.22.0 python2022.6.2 vscode-pylance2022.5.1 remote-containers0.234.0 remote-ssh0.80.0 remote-ssh-edit0.80.0 excalidraw-editor2.0.16 code-spell-checker2.1.11 svelte-vscode105.16.0 cython0.1.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Looks similar to and .
Same issue. On Mac OS, VsCode 1.67 How to reproduce: shortcut to open new window <kbdCMD</kbd+ <kbdSHIFT</kbd+ <kbdN</kbdshortcut to open new file/folder <kbdCMD</kbd+ <kbdO</kbdThe selected file/folder is now opened in the previously focused vscode window instead of the newly opened one. To solve the problem, you have to think to click in the newly opened window.

When you do so, you see the focus takes effect, proving the window was not actually focused (EDIT: What is confusing is that you can see the cursor blinking inside of the editor of the new window, even though it is not focused) I can tell this is a relatively new issue (1 or 2 months max), because I'm doing the procedure above almost every day and it has been pissing me off since then (sorry, but truly annoying).
Sounds a bit like or
Do you have configured?
This is a regression from
Thanks for the fix!
Change:
} } <del> if (this.viewsService.getViewProgressIndicator(location)) { </del> <ins> if (this.viewDescriptorService.getViewDescriptorById(location) !== null) { </ins> return this.withViewProgress(location, task, { ...options, location }); } throw new Error(`Bad progress location: ${location}`); <ins> }; if (typeof location === 'string') { return handleStringLocation(location); </ins> } switch (location) {

Discussion:
Issue Type: <bBug</bInsiders with a fresh user-data-dir in which progress-sample has been modified to target rather than . the extension (npm install) and launch it in Extension Host from 'Run and Debug'. EH Command Palette use the 'Show Progress' command that the extension contributes. Confirm that the clock decoration appears for around 5 seconds on the Source Control icon in Activity Bar. the Source Control icon over the Explorer icon, then onto the Explorer view container when its contents appear. the SOURCE CONTROL header from Explorer view back onto Activity Bar. -run the 'Show Progress' command. Observe that the clock decoration fails to appear :bug: recover the correct behaviour, run the 'View: Reset View Locations' command. Now when you run 'Show Progress' the clock appears for 5 seconds as expected. VS Code version: Code - Insiders 1.62.0-insider (, 2021-10-15T05:16:57.817Z) OS version: Windows_NT x64 10.0. Restricted Mode: No <!-- generated by issue reporter --
I think this bug is in the area of management of views and view containers, so maybe for From a user perspective step 6 in my repro reverts the effect of step 5, but internally something must be different when step 7 happens compared to how it was at step 4. I didn't notice the problem immediately after I had experimented with moving the Source Control view because no SCM operations were occurring at that time. Later I started wondering why the clock wasn't appearing when it should, and I initially thought my source control integration was broken.
the problem here is that the progress location code always directs progress badges for SCM to the original view container. This repro effectively moves all views from SCM in to the explorer, then moves a single view into the activity bar creating a new (with a different id) view container for scm. I believe the appropriate thing here is to direct scm progress location to the scm view itself (as opposed to the view container) and we can look up its current location. Sample fix
the area of code your proposed change is in makes me wonder if the same problem can occur with progress badges that target Explorer and Extensions. The API doesn't let extensions target those view containers, but maybe core code already targets them.

the original explorer and extensions view containers at the moment cannot be moved/removed. that used to be true for scm as well before work was done to allow scm to be moved as well. so today its not an issue, but you are right that it could be in the future.
I have taken the changes from your sample fix but they end up with the following error:
branch?
-
Thanks I have tested and checked in the changes.