jiebi/CodeConvo huggingface dataset:
Change:
import { KeybindingWeight } from 'vs/platform/keybinding/common/keybindingsRegistry'; import { ParameterHintsWidget } from './parameterHintsWidget'; <del> class ParameterHintsController extends Disposable implements IEditorContribution { </del> <ins> export class ParameterHintsController extends Disposable implements IEditorContribution { </ins> public static readonly ID = 'editor.controller.parameterHints';

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: Version: 1.78.2 Commit: Date: 2023-05-10T14:39:26.248Z Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.78.2 Chrome/108.0.5359.215 Electron/22.5.2 Safari/537.36 Steps to Reproduce: Jupyter extension a dummy extension and install it: Interactive Window shows up shows up signature help works on new files though, just not in the interactive.
Change:
}); 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); });

Discussion:
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.
Change:
run: yarn --frozen-lockfile --network-timeout 180000 - name: Compile and Download <del> run: yarn npm-run-all --max_old_space_size=4095 -lp compile "electron x64" </del> <ins> run: yarn npm-run-all --max-old-space-size=4095 -lp compile "electron x64" </ins> - name: Run Unit Tests id: electron-unit-tests

Discussion:
Builds:
fyi
Attempting a fix by simply doubling the max memory available to V8.
Again in
Then I'm out of ideas. we might need to split all those mangling tasks into independent processes, if memory limits are being hit.
Are we sure that we are on the right track here? According to my counting (below) we have only a tenth of the code in extensions (compare to the src-folder) so I wonder why mangling would eat up so much memory here?
I am not sure OOM is the symptom here actually, just my best hunch, but it seems is indeed the problem: <img width="913" alt="image" src=""
Added a every 1 second log of memory usage to this task: Build running:
Created to log the memory usage after each mangling step
lol - similar idea here:
I think we are on to something here. The memory is growing a lot, maybe some state leaks when mangling the next extension. Each extension is its own tsconfig and mangling context. This shouldn't pile up but memory should be released inbetween
Can you take a look at this? I put my money on this which keeps its mangler around. Looks like we need some webpack hook to dispose that loader
I gave it a stab at for which I have confidence, running locally shows how memory is growing and shrinking! This isn't a webpack change but just some cleanup in the mangler itself
!
Change:
/** * Sets a mark/point-of-interest in the buffer. `OSC 1337 ; SetMark` */ <del> SetMark = 'SetMark' </del> <ins> SetMark = 'SetMark', /** * Reports current working directory (CWD). `OSC 1337 ; CurrentDir=<Cwd> ST` */ CurrentDir = 'CurrentDir' </ins> } /**

Discussion:
Part of We want to support other common shell integration sequences as fallbacks to the VS Code specific one ()
can you add verification steps for this?
On Windows Disable shell integration Open pwsh 7+ Run the following: It should change the terminal tab's description to .

Part of We want to support other common shell integration sequences as fallbacks to the VS Code specific one ()
can you add verification steps for this?
Disable shell integration Open pwsh 7+ Run the following: It should change the terminal tab's description to .

Part of We want to support other common shell integration sequences as fallbacks to the VS Code specific one () Code pointer:
I'm taking this.
sounds good
I've just submitted the PR. You can check it anytime you want.
can you add verification steps for this?
Disable shell integration Open pwsh 7+ Run the following: It should change the terminal tab's description to .
Change:
@IWorkbenchEnvironmentService private readonly _environmentService: IWorkbenchEnvironmentService, @ILifecycleService lifecycleService: ILifecycleService, @IEditorGroupsService editorGroupsService: IEditorGroupsService, <del> @IConfigurationService configService: IConfigurationService, </del> <ins> @IConfigurationService private readonly _configService: IConfigurationService, </ins> @ISplashStorageService private readonly _partSplashService: ISplashStorageService ) { lifecycleService.when(LifecyclePhase.Restored).then(_ => {

Discussion:
! cc
is this with latest from main, eg out of source? I believe there is no insiders with the larger titlebar (due to CC)
the activity bar also changes size... there must be more to it. I guess rapid render is getting wrong values. Do you use zoom?
Correct, this is main on OSS. Confirmed that I wasn't zoomed.
is there some conflict of zoom here? Even the watermark renders for a bit slightly enlarged before shrinking?
I can only reproduce with zoom enabled, e.g zoom in once or twice reload workbench rapid render but also water mark are wrongly sized during load
LGTM other than the window controls overlay (WCO), which is being tracked at
Change:
this._subscriptions.push(domEvent(document.body, 'keydown')(e => { this.isPressed = e.altKey || ((isWindows || isLinux) && e.shiftKey); })); <del> this._subscriptions.push(domEvent(document.body, 'keyup')(e => this.isPressed = false)); </del> <ins> this._subscriptions.push(domEvent(document.body, 'keyup')(e => { if (this.isPressed) { if (this._suppressAltKeyUp) { e.preventDefault(); } } this._suppressAltKeyUp = false; this.isPressed = false; })); </ins> this._subscriptions.push(domEvent(document.body, 'mouseleave')(e => this.isPressed = false)); this._subscriptions.push(domEvent(document.body, 'blur')(e => this.isPressed = false)); // Workaround since we do not get any events while a context menu is shown

Discussion:
Issue Type: Bug the Menu Bar to be hidden +Click on one of the editor/title toolbar buttons (for example in GitLens if you Alt+Click on the Blame button it will show the recent changes rather than the blame) :bug: Observe that when you let go of the key the menu bar will toggle back on FYI, I have a PR ready to submit for this VS Code version: Code - Insiders 1.21.0-insider (, 2018-02-26T05:18:08.801Z) OS version: Windows_NT x64 10.0. <details<summarySystem Info</summary </detailsReproduces without extensions <!-- generated by issue reporter --
thanks for your PR, however let's first get the bug straigthend out. explorer. alt key, trigger context menu -notice there is "Delete Permanently" go of the all key -notice there is "Delete Permanently" still there. I just verified on windows. Is this unexpected for you? Becuase it behaves just fine for me. Or is the issue only visible for extensions? Is step 1. really needed to repro? If yes how do you hide the Menu Bar fyi
I can repro my issue on Windows/Linux - but the Menu Bar must be hidden (View -Toggle Menu Bar). Hold down and click on any of these icons (granted only the GitLens one actually has an alternate command) ! When you let go of the key it will cause the Menu Bar to be shown. As for your issue, I can't even get a context menu to show up while holding down -- well it shows for a second and disappears. And that doesn't matter if the menu bar is hidden or not.
This seems to be an issue with the alt key on windows and this feels like a duplicate of
the issue you mentioned, yes -- that is a duplicate of , but the issue I mentioned is not. There is no issue with the key not working. It it just that if you hide the menu bar (on Windows/Linux) you can use the key alone to toggle it on and off. Which is perfectly fine and as-designed.

But if you attempt to on an item in a "toolbar" (see the image in my previous post), the leaks through that click (the command works fine, mind you) so that not only does the command run, but the menu bar toggles (and it drives me NUTS ). There was similar work done to stop this from happening when +clicking in the editor here:
Ok thanks for more info. fyi
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Change:
* Split search paths (./ or ../ or absolute paths in the includePatterns) into absolute paths and globs applied to those paths */ private expandSearchPathPatterns(searchPaths: string[]): ISearchPathPattern[] { <del> if (this.workspaceContextService.getWorkbenchState() === WorkbenchState.EMPTY || !searchPaths || !searchPaths.length) { </del> <ins> if (!searchPaths || !searchPaths.length) { </ins> // No workspace => ignore search paths return []; }

Discussion:
VSCode Version: 1.33.1 OS Version: WindowsNT x64 10.0. Steps to Reproduce: folder (Ctrl+K F) a search on specified path through Ctrl+Shift+F ! With literally any folder on my system opened search works: ! I'm not sure if this is intended behavior, as the message suggests that it shouldn't work if I don't have that particular_ folder currently opened anyways, and yet it does if I open anything. Does this issue occur when all extensions are disabled?: Yes
I was just about to file an issue to find out if searching an arbitrary folder / folder tree was even possible since the note says only the currently opened folder will be searched. This is one of the things Sublime has that I was hoping VS Code had. I never tried opening any ol' folder and giving it a run.
, can i take a look at this ?
Should fix the message 'You have not yet opened a folder. Only open files are currently searched - Open Folder' makes it sound like my searches will fail with no folder open, but as long as I plug a path in it works like the issue specifies. Maybe add something along the lines of 'unless a path is specified'
I could say, "You have not opened or specified a folder, ..." I'm not sure if that's too wordy, I don't think a warning message has to explain how the whole thing works, what do you think?
Make sure you reopen issues when they are "verification-found"
This would work. How would it work once I specified a folder but haven't hit send would the message go away due to having a valid path?
No, I think it should just be updated once when the search actually runs
That seems like it would work, it would at least imply that the action being performed would work.
Now it makes more sense !
Change:
align-items: center; } <ins> .notebook-text-diff-editor .cell-diff-editor-container .input-header-container, .notebook-text-diff-editor .cell-diff-editor-container .output-header-container, .notebook-text-diff-editor .cell-diff-editor-container .metadata-header-container { cursor: pointer; } </ins> .notebook-text-diff-editor .cell-diff-editor-container .input-header-container .property-toolbar, .notebook-text-diff-editor .cell-diff-editor-container .output-header-container .property-toolbar, .notebook-text-diff-editor .cell-diff-editor-container .metadata-header-container .property-toolbar {

Discussion:
Testing These: ! Look similar, but not quite the same, as these other tree/accordion elements we have ! ! ! Off the top of my head, it probably makes the most sense to align to the tree view both from a styling and interaction POV. For example, the collapsible sections in the notebook diff and only be expanded/collapsed by clicking on the chevron. In tree views/views/settings TOC, you can click anywhere on the containing element. It also looks like I can't focus on the element to expand/collapse with just the keyboard.
Duplicate of
looks good to me (I can click anywhere to expand), but maybe should take another look since I don't see much inconsistency in those screenshots.
Change:
hide(statusbarPart.container); } <del> updateEditorPartHeight(fromEvent); } function updateEditorPartHeight(fromEvent: boolean): void { editorPartContainer.style.height = `calc(100% - ${computeEditorPartHeightOffset()}px)`; </del> if (fromEvent) { auxiliaryWindow.layout(); }

Discussion:
Testing a workspace a tab into a new floating window in a couple times using keyboard shortcuts the zoom status bar item to zoom out. When the zoom out happens, the status bar item will move further right, as expected because everything is getting small. However, the hover itself moved further left. I would expect it to either stay under my cursor (ideal) or move with the status bar item. !
It also moves around unexpectedly when I zoom in.
My cursor isn't showing properly in this gif, but I think you can get the idea. !
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Change:
"native-watchdog": "0.3.0", "node-pty": "0.7.6", "semver": "^5.5.0", <del> "spdlog": "0.6.0", </del> <ins> "spdlog": "0.7.1", </ins> "sudo-prompt": "8.2.0", "v8-inspect-profiler": "^0.0.8", "vscode-chokidar": "1.6.2",

Discussion:
Steps to Reproduce: reproduces out of sources and open just one window to date settings and go back in time 1 month =this takes 10-20s on my system. When I comment out in the as well as I can no longer reproduce. !
Investigating. Just by changing the month back, the CPU goes crazy: !
We're hitting this all the time, since is negative in this case! So CPU just spins.
wow
Moving to March due to high risk change, and given that no users seem to hit this often. Sorry for taking so long to look at this.
Snowplowed once again...
This mechanism seems to have changed in spdlog 0.17.0. Will create a new build based on that and test.
Yep, that version of spdlog fixes it! :fireworks: Lets just hope it doesn't break other things. :seenoevil:
This can't be reproduced on managed computers as we aren't allowed to change the date. can you change your date?
Never mind, there's a different UI for date changing which isn't blocked.
Change:
"main": "./out/extension", "browser": "./dist/browser/extension", "contributes": { <ins> "walkthroughs": [ { "id": "tempNodejsWelcome", "title": "tempNodejsTitle", "description": "tempNodejsDescription", "steps": [], "when": "false" } ], </ins> "jsonValidation": [ { "fileMatch": "package.json",

Discussion:
Start VS Code from fresh user data directory and extensions directory Reload Window Welcome page is broken Sanity checking VSCodeSetup-ia32-1.78.0. When launching VS Code the welcome screen opens but content never shows up ! I tested the install in a Windows Sandbox close the welcome screen close VS Code open VS Code again opens with working welcome screen.
Closing VS Code and reopening it ended it the same endless loop in the welcome screen.
Same behavior with the Zip install.
Did not happen with the User install. May be some timing issue.
Workaround close the welcome screen close VS Code open VS Code again opens with working welcome screen.
Starting with a fresh Sandbox revealed the same behavior.
Do you see any errors in the console?
Nothing in the console <img width="993" alt="capture" src="https://user-"
Found this in the extension host log:
Exception is also present when Welcome page opens correctly.
based on the error from , looks like this commit was not released and consumed in VSCode
Created separate issue for module loading - . I believe these two are unrelated.
Yes I also believe those are unrelated: Welcome screen works well for me, but I can see the same error in extension host.
A custom version of (that does not disable the welcome screen), hints to this commit range:
Some things I know It only happens when the welcome page is opening during startup- if you disable the welcome page and open it manually, it works It sometimes starts working, then doesn't break again (see Dirk's workaround above) It seems to usually work when I haven't disabled all my extensions Here's what I see when I debug in devtools 64-bit build at , is undefined 32-bit build is is empty we wait on , this never resolves In the service at , this is never called, makes sense since there are no extensions. That code is suspicious
Change:
return; } <del> const extensionName = 'German Language Pack for Visual Studio Code'; </del> await app.workbench.extensions.openExtensionsViewlet(); <del> await app.workbench.extensions.installExtension(extensionName); </del> <ins> await app.workbench.extensions.installExtension('ms-ceintl.vscode-language-pack-de', 'German Language Pack for Visual Studio Code'); </ins> await app.restart({ extraArgs: ['--locale=DE'] }); });

Discussion:
Extensions smoke tests are failing
This was caused because of two reasons has changed their search strategy and looking for extension by name is broken - label of an extension has string which was a bug introduced recently. Fixed them here -
Change:
width: initial; font: inherit; height: 26px; <del> padding: 2px 8px; </del> <ins> padding: 2px 6px; </ins> } .settings-editor > .settings-body .settings-tree-container .setting-item-new-extensions {

Discussion:
Looking at ways to make VS Code feel ever so slightly more approachable. A subtle 2px border radius on our common input components could be one way to make the UI feel more inviting and less harsh: <img width="361" alt="CleanShot 2022-04-08 at 14 48 52 src="https://user-"<img width="522" alt="CleanShot 2022-04-08 at 14 55 52 src="https://user-"<img width="494" alt="CleanShot 2022-04-08 at 14 58 01 src="https://user-"<img width="437" alt="CleanShot 2022-04-08 at 14 49 46 src="https://user-"<img width="500" alt="CleanShot 2022-04-08 at 15 01 55 src="https://user-"! FWIW, we already use a border radius on our icon buttons: <img width="300" alt="CleanShot 2022-04-08 at 15 03 36 src="https://user-"cc
I like this idea for buttons. I am not so sure about input/combo boxes.
I'm a +1 on this one, I think the inputs might need a bit of spacing from the side to feel more natural. We should also make sure that our labels are distinguishable as they start looking similar. Maybe we update the labels to be more pill-like?
As in padding L/R? I think they are indeed a bit different from our dropdowns if memory serves. Good call on the labels/tags.
Border-radius on buttons was merged but inputs is still under discussion so I'll keep this one open.
Good job
Change:
// Single Monitor: be strict about x/y positioning if (displays.length === 1) { <del> const displayBounds = displays[0].bounds; // Careful with maximized: in that mode x/y can well be negative! if (state.mode !== WindowMode.Maximized && displayBounds.width > 0 && displayBounds.height > 0 /* Linux X11 sessions sometimes report wrong display bounds */) { if (state.x < displayBounds.x) { state.x = displayBounds.x; // prevent window from falling out of the screen to the left </del> <ins> const displayWorkingArea = this.getWorkingArea(displays[0]); if (state.mode !== WindowMode.Maximized && displayWorkingArea) { if (state.x < displayWorkingArea.x) { state.x = displayWorkingArea.x; // prevent window from falling out of the screen to the left </ins> } <del> if (state.y < displayBounds.y) { state.y = displayBounds.y; // prevent window from falling out of the screen to the top </del> <ins> if (state.y < displayWorkingArea.y) { state.y = displayWorkingArea.y; // prevent window from falling out of the screen to the top </ins> } <del> if (state.x > (displayBounds.x + displayBounds.width)) { state.x = displayBounds.x; // prevent window from falling out of the screen to the right </del> <ins> if (state.x > (displayWorkingArea.x + displayWorkingArea.width)) { state.x = displayWorkingArea.x; // prevent window from falling out of the screen to the right </ins> } <del> if (state.y > (displayBounds.y + displayBounds.height)) { state.y = displayBounds.y; // prevent window from falling out of the screen to the bottom </del> <ins> if (state.y > (displayWorkingArea.y + displayWorkingArea.height)) { state.y = displayWorkingArea.y; // prevent window from falling out of the screen to the bottom </ins> } <del> if (state.width > displayBounds.width) { state.width = displayBounds.width; // prevent window from exceeding display bounds width </del> <ins> if (state.width > displayWorkingArea.width) { state.width = displayWorkingArea.width; // prevent window from exceeding display bounds width </ins> } <del> if (state.height > displayBounds.height) { state.height = displayBounds.height; // prevent window from exceeding display bounds height </del> <ins> if (state.height > displayWorkingArea.height) { state.height = displayWorkingArea.height; // prevent window from exceeding display bounds height </ins> } }

Discussion:
A fresh install of Code - stable, insiders and code-oss - will spawn a floating window relative to the top of the screen, not to the work area. Code stores the window position, so moving the window makes it spawn in the new location next time. ! Issue Type: <bBug</bSteps to reproduce: Taskbar at top of screen Display resolution: 1366x768 Install fresh copy of Code. Run Code (with or without extensions disabled) VS Code version: Code 1.23.1+ OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
via
Change:
const foldHintTop = element.layoutInfo.previewHeight; this._container.style.top = `${foldHintTop}px`; <del> } else if (element.foldingState === CellFoldingState.Expanded) { </del> <ins> } else { </ins> DOM.hide(this._container); } }

Discussion:
[ ] Notebooks (.ipynb files) [X] Interactive Window and/or Cell Scripts (.py files with #%% markers) During using folding and unfolding the text "cells hidden ..." is rendered inappropriate. The problems occur when many usages of folding are. There is an example: ! There is an example file: 67.2 v2022.4. No response No response No response No response Local
Thanks for filing this issue, we've run into similar issues in the past. The animated gif really helps here. thanks
Rendering collapsed cells is core code.
Have we? I don't remember seeing this before. But I can repro it