jiebi/CodeConvo huggingface dataset:
Code change:
previewManager.activePreview?.zoomOut(); })); <ins> disposables.push(vscode.commands.registerCommand('imagePreview.copyImage', () => { previewManager.activePreview?.copyImage(); })); </ins> return vscode.Disposable.from(...disposables); }

Related discussion:
text: Basically in the core webview module (see ), three default context menu actions (cut, copy and paste) are to the menu, which are accessible throughout all webviews, and happens to be one of them, so after you right-click anywhere in a image previewer, you will be able to see these three actions. After you clicks one of these actions, the editor will post an message to the image previewer, telling it to cut, copy or paste. If there is a correspondent listener for this perpose, the image will be actually cut, copied, pasted, but unfortunately there is no such listeners defined. This problem has existed for quite a bit of time. The original modification that cause this problem is from here . It is origianlly meant to allow users to copy selected text within an extension's README page. There is also a closed issue that describe such issue in . Personally I think providing action cut, copy and paste for all webviews is a little bit hasty, since there are not universally required for each webview, and even some of them need, the subject to be copied may vary from different webviews, or even different places in a same webview. I can solve it by disabling the default actions first (there is a option to achieve this), then let image previewer to implement its own copy and cut functionality, but I think this is rather a quick and sloppy solution. There should be another better way to solve this issue.
What about adding a handler :
Here's what I tried VSC insiders without any extensions Open a folder with a .png file Open the png file in vscode Right click and select Paste into folder in vscode = does not work Paste into markdown cell in vscode = does not work What am i doing wrong?
Pasting image data into folders isn't supported by VS Code. Pasting into a notebook cells works fine for me though. To verify though you can also paste into an external image editor
Code change:
disturl "https://electronjs.org/headers" <del> target "25.8.0" ms_build_id "23503258" </del> <ins> target "25.8.1" ms_build_id "23779380" </ins> runtime "electron" build_from_source "true"

Related discussion:
text: Version 1.74.0, when I open the developer tools, it becomes a floating window, which is very unfriendly for extension developers, please add at least one option to use the old layout. !
Was caused by an upstream electron bug with WCO Believe there are plans to restore the docking feature in the near future now that the electron issue is resolved.
I found that if you toggle OFF the setting, Developer Tools docking functionality is restored AND you also still get the WCO experience (perhaps that's a separate bug?). Suggest docking at the bottom instead of to the right if there's any visual conflict due to the aforementioned electron bug.
It work, thanks!.
The setting will be removed at one point, keeping the issue open to provide and dock options when WCO is enabled.
I manged to get it to dock again with 's workaround but I noticed in the dev tool now it shows the HTML for the VS code app instead of the file I have open in the preview !
Related Stack Overflow question:
This makes working on Windows really awful for me, I think the upstream bug is fixed.
To give some context, with WCO chromium has a bug in orienting devtools window when docked to the position where the Window controls are, basically they overlap making it harder to use the close, minimize or maximize button. Chromium always pop out the devtools window in PWA for this scenario and Electron inherited this by default. The fix in does not address the aligning behavior but rather provides a workaround that calling would be respected even in the WCO scenario rather than forcing to always detach. Now, on our end to incorporate this fix we need to change all our callsite with a mode otherwise we will default to detach as seen in this logic Say we chose as default and user later reposition it to right or left then this new state will be persisted to json file under the user data directory, in non WCO cases this saved preference will be applied next time when calling or without a mode value from the application side, that is how user's preferred position is applied. But in the WCO case, this does not take effect so we need a logic on VSCode side to read the preference value and adjust the start mode with it. I didn't want to make this change yet in core hence this issue remains open, I will tackle it in debt week.
Code change:
disturl "https://electronjs.org/headers" <del> target "25.8.0" ms_build_id "23503258" </del> <ins> target "25.8.1" ms_build_id "23779380" </ins> runtime "electron" build_from_source "true"

Related discussion:
text: I see this as an issue when you dock the devtools to the right, but why is the ability to dock it at the bottom taken away? This seems to work just fine with WCO. But on Windows, a user is not able to reposition the devtools at all? This functionality seems to be truly gone, so a setting for Windows only would be a decent workaround and good improvement over what we have today. If we decide on a setting that forces the location, I can see to do such a change.
I am good with a setting to force the bottom position only on Windows. I will see if the runtime behavior can be improved to avoid docking the devtools to the position where the controls are present as part of this issue.
The dock options are back, though setting it to dock on the right looks funny with the WCO in the way. !
Yes that is the original bug in chromium which is not addressed.
In the new version, if the developer tools are on the right side, the close button will be blocked, which is not as good as the old version of . !
use a dock position that is not overlapping with the window controls, by default the devtools will not dock to the position were the window controls are to avoid the bug.
I know, but I always put the developer tools on the right, which is where I'm most productive.
Is it possible to revert "window.experimental.windowControlsOverlay.enabled" to a VS Code new version? In order for the developer tools to be correctly positioned on the right side, I now have to go back to VS Code version 1.81 and disable updates. !
is there an issue where we are tracking how the WCO is overlapping the devtools?
no we are not tracking it in the runtime, unless you have manually docked it to the overlapping position devtools by default would be undocked. The overlapping position in the runtime will not resolved anytime soon.
Code change:
if (event.affectsConfiguration(TitlebarPart.configCommandCenter)) { this.updateTitle(); this._onDidChangeCommandCenterVisibility.fire(); <ins> this._onDidChange.fire(undefined); </ins> } }

Related discussion:
text: Toggling the command center works, but the title bar height is stuck until the window is resized. I also noticed some issues where I had to click twice to open the command center once enabled. The command center input then disappears while the command center quick pick opens.
Maybe an electron update regression
Code change:
} const outputs = viewCell.outputsViewModels; <del> for (const output of outputs) { </del> <ins> for (const output of outputs.slice(0, outputDisplayLimit)) { </ins> const [mimeTypes, pick] = output.resolveMimeTypes(this.textModel!, undefined); if (!mimeTypes.find(mimeType => mimeType.isTrusted) || mimeTypes.length === 0) { continue;

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. --Version: 1.78.0 (user setup) Commit: Date: 2023-05-03T20:09:00.748Z Electron: 22.4.8 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0. Sandboxed: No I've reported a bug related jupyter notebook before . After new release of vs code this below bug happens. Steps to Reproduce: https://user- a Jupyter notebook file that contains some images. to view images and see what happens.
I'm not seeing this repro - can you try disabling all extensions and opening that same notebook to see if it still repros? Also check which renderer is being used for the image by selecting 'change presentation' in the output menu !
I've provided info about you asked in the video. extensions are disabled was using 1. as seen in the image and video. tried other renderer as well to show difference. another issue is; VS Code is scrolling down own its own when notebook is opened first time and loading of output started. It can be observed below in end of video as well. I cannot hold the page and have to scroll back by myself. !
How many images are you displaying there? (I still don't see it with 500, though perf takes a big hit) Does it repro with a smaller number of images? Like just displaying the same image 10 times.
Code change:
} const outputs = viewCell.outputsViewModels; <del> for (const output of outputs) { </del> <ins> for (const output of outputs.slice(0, outputDisplayLimit)) { </ins> const [mimeTypes, pick] = output.resolveMimeTypes(this.textModel!, undefined); if (!mimeTypes.find(mimeType => mimeType.isTrusted) || mimeTypes.length === 0) { continue;

Related discussion:
text: Do you know if all the images are being displayed? I see some suspicious collapsed borders in between a few. Can you try and reloading to check if there's a setting causing this? ( to default to switch back)
Alright, I have tried the way you told me and created new profile and didnt install anything at all. But it seems that doesnt change. I dont have a notebook that have few images. The notebook have 618 images as it could be seen in the video before images output says that 1/618, 2/618 .... 618/618. Those are the images is saved in storage after that they are being displayed. As far as i noticed those movements only occurs when notebook is being loaded. Because if load finishes that movement seem to stop as well. Another thing is there is something wrong about loading process as it could be seen in the video. I especially didnt use mouse's wheel not to confuse you, i only used scroll bar on the right. VS Code stops loading/showing images after some point untill i scroll down bottom and if i come back it suddenly appears. And i wanted to show how google colab loads in the browser.
<!-- 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!
are there verification steps for this?
verification steps a notebook and put a small image in your local workspace a cell with the code: the cell and wait for completion, (finished for me in a few seconds) , close, and re-open the notebook the images might take a bit to all render, but they shouldn't bump up and down once they are visible
Same bug (bumping up and down) still persists for me. Another thing is loading of images are stuck some point and it's fixed if i scroll down to bottom and come back. I showed and explained the bug which was in vscode.mp4 video and duration between 00:42-1:20.
Code change:
} const outputs = viewCell.outputsViewModels; <del> for (const output of outputs) { </del> <ins> for (const output of outputs.slice(0, outputDisplayLimit)) { </ins> const [mimeTypes, pick] = output.resolveMimeTypes(this.textModel!, undefined); if (!mimeTypes.find(mimeType => mimeType.isTrusted) || mimeTypes.length === 0) { continue;

Related discussion:
text: Version: 1.79.2 (user setup) Commit: Date: 2023-06-14T08:57:04.379Z Electron: 22.5.7 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: WindowsNT x64 10.0.
This fix is only on VS Code Insiders right now. It looks like you're still using the stable version.
Code change:
<textarea name="description" id="description" placeholder="${escape(localize('details', "Please enter details."))}" required></textarea> </div> <div id="description-empty-error" class="validation-error hidden" role="alert">${escape(localize('descriptionEmptyValidation', "A description is required."))}</div> <ins> <div id="description-short-error" class="validation-error hidden" role="alert">${escape(localize('descriptionTooShortValidation', "Please provide a longer description."))}</div> </ins> </div> <div class="system-info" id="block-container">

Related discussion:
text: To prevent issues like this: and like this and many more
this is a good idea, I've been getting tagged in a lot of these recently. it's difficult to say what exactly the limit/requirements should be though. atm we require title and description (the rest of the info is fluff that is auto included). Maybe force description to be longer than 10 characters?
We can start with 10characters enforced on both title & body and see how issues keep coming. We could also maybe crowd-source ideas from the team
Code change:
import { IExtHostRpcService } from 'vs/workbench/api/common/extHostRpcService'; import { ISelection } from 'vs/editor/common/core/selection'; import { TestItemImpl } from 'vs/workbench/api/common/extHostTestingPrivateApi'; <ins> import { VSBuffer } from 'vs/base/common/buffer'; import { SerializableObjectWithBuffers } from 'vs/workbench/services/extensions/common/proxyIdentifier'; </ins> interface CommandHandler { callback: Function;

Related discussion:
text: Currently when using , ArrayBuffers just turn into an empty object. We should support these for efficient data transfer between extensions/extension hosts. We recently support for them on a protocol level, so support here should not be terribly hard...
I see two possible approaches to support this: this logic specifically for commands (or even just for a specific command). This is what we do for webviews for example: our implementation aware of array buffers instead of only supporting VSBuffers. Take a look at how is used in our rpc code as a starting point: The webview serialization logic I linked to above would probably be a good starting point for this
Code change:
weight = KeybindingWeight.ExternalExtension + idx; } <ins> let commandAction = MenuRegistry.getCommand(command); let precondition = commandAction && commandAction.precondition; let fullWhen: ContextKeyExpr | undefined; if (when && precondition) { fullWhen = ContextKeyExpr.and(precondition, ContextKeyExpr.deserialize(when)); } else if (when) { fullWhen = ContextKeyExpr.deserialize(when); } else if (precondition) { fullWhen = precondition; } </ins> let desc: IKeybindingRule2 = { id: command, args, <del> when: ContextKeyExpr.deserialize(when), </del> <ins> when: fullWhen, </ins> weight: weight, primary: KeybindingParser.parseKeybinding(key, OS), mac: mac ? { primary: KeybindingParser.parseKeybinding(mac, OS) } : null,

Related discussion:
text: contribute command that uses enablement assign a keybinding, via :bug: enablement isn't honoured
When users configure keybindings we allow them to change preconditions as well, e.g rename requires an editable document so I don't plan to have a different strategy for contributed commands
I don't see the nice "Command 'Hello World' is not enabled in the current context." info toast when I try the keybinding though. I only see that message when I try to run it from the command palette. The command correctly doesn't run when not enabled though.
Yeah, that's the design. Keybindings don't show messages
Code change:
// Note: When this action is executed from the process explorer, a config is passed. For all // other cases it is run with no arguments. <del> public run(config?: IConfig): Promise<any> { if (config && 'type' in config && 'request' in config) { return this.debugService.startDebugging(undefined, config, this.isNoDebug()); } </del> <ins> public run(): Promise<any> { </ins> const configurationManager = this.debugService.getConfigurationManager(); let launch = configurationManager.selectedConfiguration.launch; if (!launch || launch.getConfigurationNames().length === 0) {

Related discussion:
text: Somehow I missed the change in the and only now found it out. What I do not udnerstand is why we need all this code? I think this handler should be removed and the action should be called like it was done previously. Code pointer: It would be great if we could tackle this in December. Thanks
The reason for this code change was that creates a handler for command that passes no arguments to the action: So instead I used with a handler that would forward the argument. It looks like there are other debug commands registered in this way in , so I think moving the code for startDebug there makes sense. The handlers there are shorter and less generic, I'll see if rewriting the startDebug one that way causes any issues
what you need is calling the start debug with a configuration, and I believe we already have a way for doing this. can you please provide a pointer to where you are already calling start debug with a configuration. are you calling start debug from the main side or where from exactly? I can also look into this. You can just let me know how to verify that I did not break your scenario.
The extension API's implementation passes a debug configuration to the debug service's startDebugging here:
I'm trying to start debugging from the process explorer. Since it's a separate browser window, it doesn't have access to the debug workbench service, and it's also not an extension, so it can't leverage the extension API for starting debugging. Currently, the process explorer window sends an IPC message back to the issue service in the main process. This then sends an IPC message to the main renderer process to run the debug start command: The path is also used by the native menu to trigger commands from the main process.
ok got it. So the best way it seems is to what you have done going via the action. Can you try to clean up the handler. And if that does not work I can look into an alternative solution.
Sure, I'll work on cleaning up the handler today
Code change:
* ------------------------------------------------------------------------------------------ */ 'use strict'; <del> import { env, languages, commands, workspace, window, ExtensionContext, Memento, IndentAction, Diagnostic, DiagnosticCollection, Range, DocumentFilter, Disposable } from 'vscode'; </del> <ins> import { env, languages, commands, workspace, window, ExtensionContext, Memento, IndentAction, Diagnostic, DiagnosticCollection, Range, DocumentFilter, Disposable, Uri } from 'vscode'; </ins> // This must be the first statement otherwise modules might got loaded with // the wrong locale.

Related discussion:
text: VS Code does not report errors in , and then silently drops the ball without telling the user. This is particularly annoying since some things might continue working, while others mysteriously stop. Errors in come in two flavours – actual syntactical errors, but also unrecognized new properties. In particular the latter is annoying, for example when TypeScript adds new features such as (see ). My suggestion would be to at least visibly and loudly report this, but preferably be more lenient about what's accepted (e.g. unrecognized properties).
FYI
+1 I had a similar issue (non existing compiler option) and I didn't get why my configured target=es6 got not accepted. Interestingly, it worked when compiling over command line but it failed when compiling over tsserver. See also the TS compiler code. Maybe one could get that error from tsserver back to VS code?
+1 I've just had a similar issue that I've spent 3 hours working through. Adding a new typescript 2 option such as "noUnusedParameters" caused vscode to reference not , making some of my code have errors in the editor, but not when built! I've worked around by having a different that I used for building with.
See
Code change:
resolved "https://registry.yarnpkg.com/vscode-textmate/-/vscode-textmate-7.0.1.tgz#8118a32b02735dccd14f893b495fa5389ad7de79" integrity sha512-zQ5U/nuXAAMsh691FtV0wPz89nSkHbs+IQV8FDk+wew9BlSDhf4UmWGlWJfTR2Ti6xZv87Tj5fENzKf6Qk7aLw== <del> xterm-addon-search@0.9.0-beta.39: version "0.9.0-beta.39" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.39.tgz#e8376e1485ee7d763c07d1a8f1354114f65b3e3e" integrity sha512-h45wkecgfqXXoAUqgNytAfSd6g0xNT6rZy/enVaEU0aes7QoL9pxHUKkCry8PP6hs03Slk0VxQ4AGsbSZGvK/w== </del> <ins> xterm-addon-search@0.9.0-beta.41: version "0.9.0-beta.41" resolved "https://registry.yarnpkg.com/xterm-addon-search/-/xterm-addon-search-0.9.0-beta.41.tgz#0992da36fe01ff6d71449265a9dabeef7f9d0a3f" integrity sha512-b1vuWR5JZ8QIiObbKkwSzpzf4x0B9hdzGCHJG+PXWT/xbxk65DOe/X9rgrRyOnCWe5ylQGG4DIHTiREigTp0lg== </ins> xterm-addon-unicode11@0.4.0-beta.3: version "0.4.0-beta.3" resolved "https://registry.yarnpkg.com/xterm-addon-unicode11/-/xterm-addon-unicode11-0.4.0-beta.3.tgz#f350184155fafd5ad0d6fbf31d13e6ca7dea1efa" integrity sha512-FryZAVwbUjKTmwXnm1trch/2XO60F5JsDvOkZhzobV1hm10sFLVuZpFyHXiUx7TFeeFsvNP+S77LAtWoeT5z+Q== <del> xterm-addon-webgl@0.12.0-beta.41: version "0.12.0-beta.41" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.12.0-beta.41.tgz#17dbca975b6e9b34526ebc57f4de59ee295da1b6" integrity sha512-wvQxC5diMYEJEMaILfz+4CWB2GgtzjzNQRNDnK7R7Y9wDI+P4idDlQKgyH0nA93sl9R4zgqlBVha//wuq4vfZg== </del> <ins> xterm-addon-webgl@0.12.0-beta.43: version "0.12.0-beta.43" resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.12.0-beta.43.tgz#916ed4e390371403aab0d277097cd8a61be436e8" integrity sha512-hGXfwT6TOmp0tBDiS/iF8s0SLHLd3shJ5zQyS4HNtq99B5cEhHhwaUAZAfjLt5rnUt0kvqR9YWtGsDux5dWVLA== </ins> <del> xterm@4.19.0-beta.60: version "4.19.0-beta.60" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.60.tgz#de89d93153ae3ec17b53f3e5d03b8ea859126081" integrity sha512-YQjvp4xtSAyNm9+gF4OA5+QzkSWdKMCy4WABETpe7CsrEGx+mJVoXCZ9wgopmvwRXz7DeJvKM5dWz1HPjVLDtA== </del> <ins> xterm@4.19.0-beta.67: version "4.19.0-beta.67" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.67.tgz#9a7d79be64469c91bb693b9f5a50b5a22e921cd3" integrity sha512-4bYTnT6g91N5QId1qPaiSvkpsxMQYpuPdPJItvBZFOcQLTuFSX85x5NeFuDvhNqi33eMFPimyGhzH/JvAV1v/Q== </ins>

Related discussion:
text: https://user-
Related ,
happening bc the first line's marker isn't disposed of (and thus the decoration isn't either) !
so maybe we should have some API on xterm like so that can be handled specially?
oh here's the issue that solved but looks like that actually wasn't solved anyway
Just to confirm, to verify this issue, are you typing commands followed by the clear command in between? Or are you clearing the terminal another way?
Typing and clearing
Pretty sure this is the command, not run in the terminal