jiebi/CodeConvo huggingface dataset:
Code change:
const modelVersionNow = model.getAlternativeVersionId(); const { item } = event; <ins> // const tasks: Promise<any>[] = []; const cts = new CancellationTokenSource(); </ins> // pushing undo stops *before* additional text edits and // *after* the main edit if (!(flags & InsertFlags.NoBeforeUndoStop)) {

Related discussion:
text: so how do servers know that clients support lazy-loading of additional textedits? Surely this should be a client capability advertised by vscode (that needs to be specced in the LSP)
is the right person for that and you should probably create a follow up issue in the LSP land
corresponding LSP feature request created here please add more details if I miss anything.
Thanks
To verify: use TypeScript have a suggestion that will import a symbol make sure that suggestion isn't first or focused in the UI use the mouse(!) to select the suggestion make sure the import is there make sure undo, redo works as expected
Code change:
pick: async () => { // Do a late 'onDebugDynamicConfigurationsName' activation so extensions are not activated too early #108578 await this.adapterManager.activateDebuggers(onDebugDynamicConfigurationsName, type); <del> const disposables = new DisposableStore(); const input = disposables.add(this.quickInputService.createQuickPick<IDynamicPickItem>()); input.busy = true; input.placeholder = nls.localize('selectConfiguration', "Select Launch Configuration"); input.show(); const chosenPromise = new Promise<IDynamicPickItem | undefined>(resolve => { disposables.add(input.onDidAccept(() => resolve(input.activeItems[0]))); disposables.add(input.onDidTriggerItemButton(async (context) => { resolve(undefined); const { launch, config } = context.item; await launch.openConfigFile({ preserveFocus: false, type: config.type, suppressInitialConfigs: true }); // Only Launch have a pin trigger button await (launch as Launch).writeConfiguration(config); await this.selectConfiguration(launch, config.name); this.removeRecentDynamicConfigurations(config.name, config.type); })); }); </del> const token = new CancellationTokenSource(); const picks: Promise<IDynamicPickItem[]>[] = [];

Related discussion:
text: Type: <bBug</bHow to reproduce the issue: and Run the Extension the , and then the pane. Use the dropdown and select the Dynamic Configuration Provider . With the checked out branch, it will show the quick pick options for Option 1 - 3, but will not show a quick pick for the resolved configurations. This seems to work for , but not Expected: ! Actual: ! VS Code version: Code 1.77.3 (, 2023-04-12T09:16:02.548Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.78.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
I've updated to: and it still reproduces.
for prioritization help as per email thread
Sent a PR for this. But what is the inner quickpick? I'm a little unsure about the approach, I don't think we expect a provider to include some UI. Your extension doesn't own the UI in this flow- you are just implementing a provider method which will be invoked at different times, expected to return a list of configs. It might make sense in one situation to show the quick pick, but we could make changes in vscode to call your provider at a different time where it would be unexpected to have a quick pick pop up. And, any extension can implement a config provider for your debug type. So for example, multiple extensions could all be showing their own UI in this scenario. However, from memory, I think the Python debug extension might already have a similar multi-step picker UI for a scenario like this.
Code change:
"git": { "name": "electron", "repositoryUrl": "https://github.com/electron/electron", <del> "commitHash": "a5cafd174d2027529d0b251e5b8e58da2b364e5b" </del> <ins> "commitHash": "b05ccd812e3bb3de5b1546a313e298961653e942" </ins> } }, "isOnlyProductionDependency": true, "license": "MIT", <del> "version": "19.0.11" </del> <ins> "version": "19.0.12" </ins> }, { "component": {

Related discussion:
text: Found this stack while scanning through some failing smoke test runs From Deepak:
What are some verification steps for this issue?
I did check logs last week and could no longer find this.
Code change:
"git": { "name": "electron", "repositoryUrl": "https://github.com/electron/electron", <del> "commitHash": "a5cafd174d2027529d0b251e5b8e58da2b364e5b" </del> <ins> "commitHash": "b05ccd812e3bb3de5b1546a313e298961653e942" </ins> } }, "isOnlyProductionDependency": true, "license": "MIT", <del> "version": "19.0.11" </del> <ins> "version": "19.0.12" </ins> }, { "component": {

Related discussion:
text: I noticed this in smoke test runner logs leading me to think that the type of the exit code is not a but an now?
Code change:
"git": { "name": "electron", "repositoryUrl": "https://github.com/electron/electron", <del> "commitHash": "a5cafd174d2027529d0b251e5b8e58da2b364e5b" </del> <ins> "commitHash": "b05ccd812e3bb3de5b1546a313e298961653e942" </ins> } }, "isOnlyProductionDependency": true, "license": "MIT", <del> "version": "19.0.11" </del> <ins> "version": "19.0.12" </ins> }, { "component": {

Related discussion:
text: Type: <bBug</bIn the most recent insiders version, audio cues no longer play. I ensured that the audio cues I expect are enabled (e.g. error) and entered the following json as an example: I ensured that the error was reported when moving through errors with f8, yet the cue doesn't play when I come across the line with up/down arrow keys VS Code version: Code - Insiders 1.71.0-insider (, 2022-08-05T07:36:58.753Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: No <!-- generated by issue reporter --
cc
We didn't touch anything there the last months, maybe it is caused by an electron update. Will investigate for the next release.
I can reproduce this. Easy repros steps: 1 list audio cues command cues do not produce sound Works fine on latest stable. Does not work on Insiders. fyi since most likely caused by Electron update (thus adding label). Maybe our future planned ffmpeg change will fix this? thanks a lot for reporting this, and sorry about this breakage.
You're welcome, I'm running insiders for a reason Looking forward to a fix.
Let me also assign since we will now support would you like that all our audio cues are in format? If yes, would you like me to reach out to our sound designer for this? Thanks
can you track the conversion in a separate issue, this particular issue is a regression with the ffmpeg build shipped with internal builds. There was a recent build architecture change and it impacted this. I would like to close this issue as part of the next Electron version update :)
makes sense, thanks! There is actually already this one which we can use for the conversion
The same problem using code-insiders into a fedora workstation 36.
It is working again with orca.
lovely, thanks for confirming. Adding verified label.
For me it also works like a charm on Windows.
For some reason I can't explain, this issue seems to have returned on my fedora workstation. No sound is played when I move the cursor to lines that contain breakpoints, errors and etc. Version: 1.71.0-insider Commit:
Confirmed on Windows. Could tests for this be somehow?
Code change:
"git": { "name": "electron", "repositoryUrl": "https://github.com/electron/electron", <del> "commitHash": "a5cafd174d2027529d0b251e5b8e58da2b364e5b" </del> <ins> "commitHash": "b05ccd812e3bb3de5b1546a313e298961653e942" </ins> } }, "isOnlyProductionDependency": true, "license": "MIT", <del> "version": "19.0.11" </del> <ins> "version": "19.0.12" </ins> }, { "component": {

Related discussion:
text: Sorry for the regression, but this is a temporary expected breakage because we are updating our supported audio formats , audio cues will be updated to new format this iteration as part of /cc
Sorry about that We just pushed a fix, and the VS Code insiders from tomorrow will have the fix.
Thanks Given this feature turns out to be pretty important for us visually impaired users, would it be possible to create a system test for this? I assume it should be possible to throw a audio cue at FFMPEG and make it fail if the sound doesn't play?
that's a good idea. However I leave this up to since he is driving this from engineering and would have better ideas how we could test it exactly.
We would need a way to ask the OS if an application played some sound.
It works again, at least on my environment. Thanks.
awesome, thanks for letting us know.
I can confirm that it works here as well. Hopefully it stays that way
Code change:
"git": { "name": "electron", "repositoryUrl": "https://github.com/electron/electron", <del> "commitHash": "a5cafd174d2027529d0b251e5b8e58da2b364e5b" </del> <ins> "commitHash": "b05ccd812e3bb3de5b1546a313e298961653e942" </ins> } }, "isOnlyProductionDependency": true, "license": "MIT", <del> "version": "19.0.11" </del> <ins> "version": "19.0.12" </ins> }, { "component": {

Related discussion:
text: <!-- 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.66.0 (x64) OS Version: 10.0. Build (Window 10) Steps to Reproduce: VS Code (or use the shortcut ) the first miliseconds after opening a new instance of VS Code, a "Window 7"-like window frame layout appears, before the usual VS Code look shows up (see the attached GIF). The GIF below first shows the expected behavior, opening version 1.65.0, followed by the current behavior of version 1.66.0. ! The two executables were downloaded from: and
Refs
that's the reason I went back to 1.65, frames are so annoying.
Hi just a small update: I've downloaded the latest VS Code Insiders and the problem now only appears when launching VS Code for the first time, but no longer when opening new windows from a running instance of it.
This issue persists in the new latest version release, .
The issue persists in today's release, .
Since the related bug in the Electron repo has a label, and today's VSCode uses , I believe we will be experiencing this bug for months.
The upstream Electron issue is at The issue was introduced in Electron v14.0.0-beta.5 and the commit that introduced the issue is The PR fixes the issue where frameless resizable windows show Windows 7 frames during startup, but there's a larger issue that is still unresolved even with that PR.
Code change:
"git": { "name": "electron", "repositoryUrl": "https://github.com/electron/electron", <del> "commitHash": "a5cafd174d2027529d0b251e5b8e58da2b364e5b" </del> <ins> "commitHash": "b05ccd812e3bb3de5b1546a313e298961653e942" </ins> } }, "isOnlyProductionDependency": true, "license": "MIT", <del> "version": "19.0.11" </del> <ins> "version": "19.0.12" </ins> }, { "component": {

Related discussion:
text: I also searched through the thousands of to see whether they had anything to do with the issue, but I didn't find anything relevant even after reverting several suspicious commits. Running with Electron v14.0.0-beta.5 or newer on Windows 10 reproduces the issue. The PR fixes the issue for frameless resizable windows by calling at an earlier stage of program initialization. Assume the window is frameless and resizable. Then, the program sets to earlier in , and the following occurs: is not run, meaning is not removed from the style set in Line 62. This style parameter is passed in to a call at . is not run. Instead, the block above is run, which adds a style to the style passed into the call. , because of these styles being passed in, after the window is shown, we get a single message, and no messages after. NC in this case refers to non-client area, which is the frame. DWM stands for desktop windows manager. After adding a long of 30 seconds to the call above, I was able to use Spy++ to log messages to that window and see the following: I have also attached full logs to the end of this comment. For frameless windows that cannot resize, even if we call earlier, because the program would pass in , for the and calls above, the style would not be in the styles sent to the calls. As a result, what I see in Spy++ is being toggled three times, and several calls that result in messages being emitted. Using Spy++, I confirmed that the calls have the flag set. I have searched the Chromium and Electron codebases for and (as well as ) to see why the frame might be rendering more often when is not passed in. However, I haven't found anything within the codebase itself. Searching Windows documentation, I found the following: causes to be sent. Reference: However, I'm not sure whether this could explain the difference in behaviour between resizable and non-resizable windows. can pass in or to send to the window, which is why I searched for those two constants within the codebase. Reference: Also, Chromium handles by returning at , which I assume causes the message to occur. Also, Electron calls at .
Code change:
"git": { "name": "electron", "repositoryUrl": "https://github.com/electron/electron", <del> "commitHash": "a5cafd174d2027529d0b251e5b8e58da2b364e5b" </del> <ins> "commitHash": "b05ccd812e3bb3de5b1546a313e298961653e942" </ins> } }, "isOnlyProductionDependency": true, "license": "MIT", <del> "version": "19.0.11" </del> <ins> "version": "19.0.12" </ins> }, { "component": {

Related discussion:
text: I noticed that if I don't call there, the Windows 7 frame doesn't show up, but then the Electron window doesn't render with the proper style (see ). I also noticed that when the Windows 7 frame shows up, it has the style of whatever was passed into that specific call. For example, if I add to the call, then for a second I see a Windows 7 frame with applied. I also tried creating a minimal project in VS to reproduce the issue but wasn't successful. The frame that rendered seemed to have a Windows 10 style rather than a Windows 7 one. I also tried registering a listener in for the messages, and it did seem to get hit, though I couldn't do anything with it. There's also the mysterious , but I wasn't able to apply it to resolve the issue.
The PR that linked above (partially based on ) should resolve the issue for VS Code Insiders and hence close this issue, but there's still more I'd like to investigate, especially for frameless non-resizable windows. I some lines to log the hwnd and style passed into each relevant and call. One example of the styles that show up: There's also another window being created really early, but I don't think it influences the issue. Good scenario (meaning no frame showing) with set to and staying Bad scenario with set to then Bad scenario with set to and staying The call with style causes the Windows 7 frame to render, and its style corresponds to is actually the same style just with , once again showing how mysterious the constant is. While working on , I also noticed that changing the order of the calls seemed to fix the issue for frameless non-resizable windows. In particular, on the Electron side, in , if I first called to pretend that the window is resizable, and then called (where ) after the call around line 365, then the issue is resolved even for frameless non-resizable windows. However, this workaround delays the call to hundreds of lines later, and I wouldn't be surprised if it would cause a regression elsewhere. Just like in the log file of the good case of the previous comment, only shows up once, rather than three times. For completeness, here are the logs with the styles for this scenario, excluding the logs: In this case, the style never comes up!
Code change:
"git": { "name": "electron", "repositoryUrl": "https://github.com/electron/electron", <del> "commitHash": "a5cafd174d2027529d0b251e5b8e58da2b364e5b" </del> <ins> "commitHash": "b05ccd812e3bb3de5b1546a313e298961653e942" </ins> } }, "isOnlyProductionDependency": true, "license": "MIT", <del> "version": "19.0.11" </del> <ins> "version": "19.0.12" </ins> }, { "component": {

Related discussion:
text: I also tried delaying the call and calling instead of , but that doesn't work because it fails to pass to the call as well as the first call, both of which need for the frame not to render: can be used to change the non-client (NC) rendering policy and hence result in a call. However, I did not find any references to within the Electron and Chromium codebases that were actually called when running my minimal repro.
lets continue the investigation in
<!-- 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!
/verified
Code change:
|| installedExtension.preRelease !== e.preRelease // Install if the extension pre-release preference has changed ) { if (await this.extensionManagementService.canInstall(extension)) { <del> this.logService.trace(`${syncResourceLogLabel}: Installing extension...`, e.identifier.id, extension.version); await this.extensionManagementService.installFromGallery(extension, { isMachineScoped: false, donotIncludePackAndDependencies: true, installPreReleaseVersion: e.preRelease, profileLocation: profile.extensionsResource } /* set isMachineScoped value to prevent install and sync dialog in web */); this.logService.info(`${syncResourceLogLabel}: Installed extension.`, e.identifier.id, extension.version); removeFromSkipped.push(extension.identifier); </del> <ins> extensionsToInstall.push([e, extension]); </ins> } else { this.logService.info(`${syncResourceLogLabel}: Skipped synchronizing extension because it cannot be installed.`, extension.displayName || extension.identifier.id); addToSkipped.push(e);

Related discussion:
text: I don't think the state of walkthrough progress is synced between machines, so I see this on each new machine I setup: !
Again, we do try to sync the state but there may be a race where it's not available in time. I'll investigate more..
Fixed it by adding the context to the installation event when extensions are synced by settings sync. Walk through component shall simply ignore walk through for those extensions which are installed by settings sync (irrespective of the walk through state is synced or not).
Code change:
} const cell = new MarkupCell(init.cellId, init.mime, init.content, top, init.metadata); <del> cell.element.style.visibility = visible ? 'visible' : 'hidden'; </del> <ins> cell.element.style.visibility = visible ? '' : 'hidden'; </ins> this._markupCells.set(init.cellId, cell); await cell.ready;

Related discussion:
text: Collapse an output, it is not hidden in the webview <img width="596" alt="image" src="https://user-"
maybe ?
Code change:
dispose: () => combinedDisposable(disposables).dispose() }; <del> const cacheKey = descriptor.resource.toString(); </del> <ins> const cacheKey = `${descriptor.resource.toString()}:${descriptor.etag}`; </ins> let ctrlPressed = false; let altPressed = false;

Related discussion:
text: Issue Type: <bBug</bIn VSC, load a small image, zoom in a lot, close the image. Resize the small image by 10 times. In VSC, load the resized image. VS Code version: Code 1.33.1 (, 2019-04-11T08:27:14.102Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (15)</summaryExtensionVersion ------ Bookmarks10.4.3 npm-intellisense1.3.0 vscode-eslint1.8.2 githistory0.4.6 EditorConfig0.13.0 rainbow-csv1.0.0 dotenv1.0.1 vscode-typescript-tslint-plugin1.0.0 vetur0.19.2 github-actions-vscode2.6.1 rust0.6.1 RustyCode0.19.1 vscode-hexdump1.7.2 sort-lines1.8.0 markdown-all-in-one2.3.1 (1 theme extensions excluded) </details<!-- generated by issue reporter --
I would like to take this. I think we can store more information in . In my opinion, we can add the size or add the SHA1 value of the image? Do you have any suggestions?
can i work on this?
i didn't know that already started working on this, both prs work. as far as mine considered, i'm resetting scale to 1.
I'm sorry that I didn't reply to you immediately. Do you reset the scale every time you close the image? It makes the editor cannot remember the scale and offset even the image isn't modified.
yes you are write. let me close mine. :+1:
Code change:
import { filter } from 'vs/base/common/objects'; import { assertType } from 'vs/base/common/types'; import { URI } from 'vs/base/common/uri'; <del> import { localize } from 'vs/nls'; </del> import { IRevertOptions, ISaveOptions, IUntypedEditorInput } from 'vs/workbench/common/editor'; import { EditorModel } from 'vs/workbench/common/editor/editorModel'; import { NotebookTextModel } from 'vs/workbench/contrib/notebook/common/model/notebookTextModel'; import { ICellDto2, INotebookEditorModel, INotebookLoadOptions, IResolvedNotebookEditorModel, NotebookCellsChangeType, NotebookData } from 'vs/workbench/contrib/notebook/common/notebookCommon'; import { INotebookSerializer, INotebookService, SimpleNotebookProviderInfo } from 'vs/workbench/contrib/notebook/common/notebookService'; <del> import { IExtensionService } from 'vs/workbench/services/extensions/common/extensions'; </del> import { IFilesConfigurationService } from 'vs/workbench/services/filesConfiguration/common/filesConfigurationService'; import { ILifecycleService } from 'vs/workbench/services/lifecycle/common/lifecycle'; import { IFileWorkingCopyManager } from 'vs/workbench/services/workingCopy/common/fileWorkingCopyManager';

Related discussion:
text: I don't see how we can expect a custom editor to support a scenario where its source extension isn't installed - is that even possible? I went over the issue with and concluded that we can defer to next release since the previous stable version also didn't handle this scenario well.
fyi I just created which is a similar issue for custom editors. Here for notebooks I suggest the following: if the EH restarts and still has the notebook extension for the opened notebooks, reconnect to the EH and allow to further make edits on the editor (I actually thought this was already implemented based on the work did) if the EH restarts and there is no more extension for the notebook editor, turn the notebook readonly and inform the user somehow Does that make sense?
The previous change just doesn't account for untitled notebooks, but I think I can fix that. That makes sense, although I'm surprised that we would require all custom editors to handle this (asked about it in the other issue)