jiebi/CodeConvo huggingface dataset:
Code change:
"git": { "name": "electron", "repositoryUrl": "https://github.com/electron/electron", <del> "commitHash": "84d7f7f071ae11637d4a41b95536410293672750" </del> <ins> "commitHash": "dc3ce65dd5fd872db86e5308ae005a898142435a" </ins> } }, "isOnlyProductionDependency": true, "license": "MIT", <del> "version": "25.8.0" </del> <ins> "version": "25.8.1" </ins> }, { "component": {

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:
"git": { "name": "electron", "repositoryUrl": "https://github.com/electron/electron", <del> "commitHash": "84d7f7f071ae11637d4a41b95536410293672750" </del> <ins> "commitHash": "dc3ce65dd5fd872db86e5308ae005a898142435a" </ins> } }, "isOnlyProductionDependency": true, "license": "MIT", <del> "version": "25.8.0" </del> <ins> "version": "25.8.1" </ins> }, { "component": {

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:
env: this._shellLaunchConfig.env }; <del> this._logService.trace('Spawning remote agent process', { terminalId: this.id, shellLaunchConfigDto }); </del> <ins> this._logService.trace('Spawning remote agent process', { terminalId: this._instanceId, shellLaunchConfigDto }); </ins> const result = await this._remoteTerminalChannel.createTerminalProcess( shellLaunchConfigDto,

Related discussion:
text: We should filter out the terminal if this is undefined, otherwise bad bugs like could happen where we restore a terminal into the wrong window: The chances of this happening are pretty slim so not doing this in Feb.
Falling back to 0 as it has been seems to work well, if we need to handle this on reconnect we will have a persistentProcessId of 0 which isn't valid anyway.
Code change:
import * as strings from 'vs/base/common/strings'; import * as objects from 'vs/base/common/objects'; import * as platform from 'vs/base/common/platform'; <del> import * as stdfork from 'vs/base/node/stdFork'; </del> import { Emitter, Event } from 'vs/base/common/event'; import { TPromise } from 'vs/base/common/winjs.base'; import { ExtensionsChannelId } from 'vs/platform/extensionManagement/common/extensionManagement';

Related discussion:
text: I've had a couple of people report debug adapter crashes recently. One of them I'm unable to reproduce which means I need to get more information from the user. Currently, when a debug adapter crashes, the error information that appears in the console is very vague: ! The actual exception that was thrown is not shown. Since I can't repro this, the only ways I can think of to debug are: try/catch around all debugger methods that handles errors and passes them back nicely (and remember to do this for all future methods) the user to run my project from source and debug the debug adapter to catch the error (whilst not the hardest thing in the world, it's a bit involved for an end user) Is it possible to get better information from the error back into the console without having a debugger attached to debug adapter?
I don't know if the text "ERR" in the console was actually supposed to be my error; but it isn't. My error was "AAAAAARGH".
this request makes sense. Not sure though if I am getting your error when your process crashes. Can you be so kind and set a breakpoint make your server crash and check if your message is coming through as a or as something else. Thanks
Do you mean the text? I also don't get that now when trying to repro, only the "terminated unexpectedly" message. If you still want me to try that breakpoint, can you explain how to add a breakpoint there. I did try breaking in my adapter and navigating the callstack (that file wasn't in there anywhere) and also checking the filenames of the files that were (they showed ).
I mean let's try to see if your error "AAAAARGH" surfaces on our side. You should be able to just run regular vscode, F1 open developer tools, wait some time and put a breakpoint by openning a . Also try to put a breakpoint and check if the error stream spits up something.
The breakpoint is not hit, which is perfectly normal since the exception occurs before the socket connection is created. You should be able to reproduce by adding require('unknown_module') to the top of any debugger extension .js file
Ok, I got breakpoints in both and . First wasn't called and the second was called but is and is . So seems like the message isn't there.
Code change:
import * as strings from 'vs/base/common/strings'; import * as objects from 'vs/base/common/objects'; import * as platform from 'vs/base/common/platform'; <del> import * as stdfork from 'vs/base/node/stdFork'; </del> import { Emitter, Event } from 'vs/base/common/event'; import { TPromise } from 'vs/base/common/winjs.base'; import { ExtensionsChannelId } from 'vs/platform/extensionManagement/common/extensionManagement';

Related discussion:
text: For testing, all I've done is put inside my debug adapter. Though now I think about it; the error isn't occurring in code that's been executed directly by Code - it's during the response from my debugger. In my debug adapter I spawn a process and I add a handler for . When something comes over and my callback runs, that's where the crash is occurring. I don't know if this changes things (for example, I don't know if this is on another thread?).
That one (in ) didn't seem to be hit either.
Actually, I think I can repro this really easily by just putting in the constructor of the ? Also gets .
This issue has the needs-more-info tag though I think it's easily reproducible with my last comment. Let me know if that's not the case!
I have removed tha tag and plan to look into this issue this week. Thanks
Investigated and the issue here is that I am not getting any exception data from the spawned process. I simply get the code while all the other error chanels are blank. I am not sure what would be the proper solution here. Suggestions are very welcome. Also are all your debug adapters launched using node? If yes then it might be that our  launch is somehow eating up the error if it happens on startup. If this also happens for adapters which are not realying on node to be launched then is not to blame.
please try to disable the launch for node () and see whether this makes a difference. DAs should work independent from . But make sure that the node version used is roughly the same as Electron's version (i.e. 7.9.0).
Yes, using stdfork is the cause here. If I do not use it, I nicely get the error popping up in the extensions output channel. My weekend is starting if someone is feeling smart code review and let me know if you find something fishy about stderr not being wired through.
Then you might want to involve/assign
I am going on a vacation tomorrow evening, and this is like this since forever so pushing to April to investigate with Alex what is going on behind the curatans here.
Code change:
getSelectedOrSuggestedKernel(notebook: INotebookTextModel): INotebookKernel | undefined { const info = this.getMatchingKernel(notebook); <del> return info.selected ?? (info.all.length === 1 ? info.all[0] : undefined); </del> <ins> if (info.selected) { return info.selected; } const preferred = info.all.filter(kernel => this._kernels.get(kernel.id)?.notebookPriorities.get(notebook.uri) === 2 /* vscode.NotebookControllerPriority.Preferred */); if (preferred.length === 1) { return preferred[0]; } return info.all.length === 1 ? info.all[0] : undefined; </ins> } // default kernel for notebookType

Related discussion:
text: Currently in VS Code when users open a notebook document, they don't need to pick a kernel manually only in following two scenarios: The notebook was opened before and users run the notebook against a kernel already. That kernel will be picked automatically, no other kernel would replace it unless users pick one manually. There is only one kernel contributed to this notebook. When users run a cell, and there is still only one kernel, the kernel will be used. Before users run any cell, and there are more than one kernel, the kernel picker will not show any active kernel info (it shows "Select kernel" instead). Above two scenarios cover two use cases: open an existing notebook, or work on single controller notebook (e.g., GitHub issue notebook). However this doesn't cover two common workflow open their existing Jupyter notebook (created through other Jupyter frontend/service) in VS Code create new Jupyter notebooks when they have already specified their preferred kernel Especially that VS Code is still growing to be one of data scientists' Jupyter frontend/editor, almost every new users will run into workflow 1 and do manual kernel picking though often Jupyter has a good guess which kernel is preferred for current document, and also every existing would run into workflow 2. The concrete issues reported: [AZML/Open in VS Code] on AZML website, click open in VS Code, it opens a remote window and opens the notebook document in the editor. No kernel is not picked though users already specify one in AZML website. notebook A in File Explorer, pick a kernel. Create notebook B in File Explorer, the kernel info is back to "Select Kernel" again. untitled notebook in Editor Area, pick a kernel and run. Save as a new notebook document on disk, the new document has no selected kernel. . Create a notebook in JuliaLab, specify a kernel. Open the notebook then in VS Code, preferred kernel not selected. Proposals For AZML/Julia users, they are mostly working on single language notebook (other than polyglot), meaning the notebook serializer is the ipynb extension we ship out of the core, and kernels/controllers are contributed by a single notebook extension installed from the marketplace (Julia, or .NET, or Jupyter). If this is the case, we can pick the kernel whose affinity is the only highest without prompting users to pick one.
Code change:
getSelectedOrSuggestedKernel(notebook: INotebookTextModel): INotebookKernel | undefined { const info = this.getMatchingKernel(notebook); <del> return info.selected ?? (info.all.length === 1 ? info.all[0] : undefined); </del> <ins> if (info.selected) { return info.selected; } const preferred = info.all.filter(kernel => this._kernels.get(kernel.id)?.notebookPriorities.get(notebook.uri) === 2 /* vscode.NotebookControllerPriority.Preferred */); if (preferred.length === 1) { return preferred[0]; } return info.all.length === 1 ? info.all[0] : undefined; </ins> } // default kernel for notebookType

Related discussion:
text: cc
Had discussions with about this. In addition to the proposal mentioned above (optimizing the single extension contributing multiple kernels scenario), another idea came out of our discussions: Allow users to choose the default kernel. One example is users have both Jupyter and Julia extensions and both of them contribute notebook controllers for Julia execution. Users might have their preference for the default kernel, allowing them to specify which kernel should be the default can help avoid users picking the default kernel in every newly opened notebook.
I thought about filing a new feature request on this. But it seemed better to keep the discussion contained here, at least for now. In particular it relates to the last comment about selecting a default kernel as well as the Gear icon for the notebook controller. Speaking personally, the majority of my issues with kernel selection would be alleviated by the ability to select a kernel to be my default, auto-selected kernel at both the global level with the ability to override it at the workspace / resource level, just like the rest of VS Code settings. All the rest of selection could work like it currently does. But I want the ownership to be able to explicitly specify kernel selection with some type of manual affordance that always trumps any type of heuristics or metadata or forcing a manual selection. At a surface level I like it as just a setting, but the issue here is that controller IDs are not something that's exposed to the User. The Gear icon might be the right place to surface this, and might have even been what the Gear icon did before (it does nothing now for me in insiders).
Agree 100%. Even though we could save the controller id to settings when users use the gear icon, it's not great as users won't be able to read or tweak this specific setting as the controller ids are not always human readable. With that said, we could tackle this differently to archive the same thing, instead of asking controller id, we could ask users if they want to use the lastly used controller, use a controller suggested by extensions always, use a controller which matches the workspace stats the most (use Julia controller if the workspace stats are all around Julia files).
Yeah, that's the challenge here. Controller ids aren't nice to read and not guaranteed to be constant. A better concept is user state, e.g mementos, which also roam across machines.
Code change:
getSelectedOrSuggestedKernel(notebook: INotebookTextModel): INotebookKernel | undefined { const info = this.getMatchingKernel(notebook); <del> return info.selected ?? (info.all.length === 1 ? info.all[0] : undefined); </del> <ins> if (info.selected) { return info.selected; } const preferred = info.all.filter(kernel => this._kernels.get(kernel.id)?.notebookPriorities.get(notebook.uri) === 2 /* vscode.NotebookControllerPriority.Preferred */); if (preferred.length === 1) { return preferred[0]; } return info.all.length === 1 ? info.all[0] : undefined; </ins> } // default kernel for notebookType

Related discussion:
text: Something already exists but it isn't utilised properly and might need further tweaking. The knows and persists what kernel was used most recently for what . Maybe it's enough to make more brave kernel selections based on that information
Code change:
} run(accessor: ServicesAccessor) { accessor.get(ITerminalService).doWithActiveInstance(t => { <del> t.xterm?.markTracker.scrollToPreviousMark(); </del> <ins> t.xterm?.markTracker.scrollToPreviousMark(undefined, undefined, t.capabilities.has(TerminalCapability.CommandDetection)); </ins> }); } });

Related discussion:
text: Notice how for the task terminal it jumps all the way to the top on the first ctrl+up, instead of going to the most recently run task: !
When I run the build task and do cmd + up, the window crashes !
That's even worse
the call to get markers here returns undefined !
I bet the markers are getting disposed of, so deleted from the map in but it looks like that wouldn't even happen since we don't set like we should. Could be why I see the renderer process crash?
Code change:
public async run(accessor: ServicesAccessor | undefined, editor: ICodeEditor): Promise<void> { const controller = InlineCompletionsController.get(editor); <del> controller?.model.get()?.acceptNextLine(controller.editor); </del> <ins> await controller?.model.get()?.acceptNextLine(controller.editor); </ins> } }

Related discussion:
text: One desired behavior of writing a custom is that when the user accepts a given suggestion, the provider is immediately triggered again for another suggestion. We need to track when users accept (or reject) suggestions so that we can measure improvements that we make. Without using the experimental API, the best way to track if a completion is accepted is to provide a value for the field in . When supplying a command, the retriggering behavior is disabled [1]. As a workaround, I tried to indirectly trigger an inline completion via the command , however, it does not work (not sure why, this does work with my unit tests but not when I try to call it from a command I supply via ). [1] I believe this is the code block that retriggers automatically, one can see that the retrigger only happens if the command is the default command:
Note is related.
Note that [1] points to the autocomplete source code, not the inline suggestion feature. I'm not aware of any disablements.
Ok, that's incorrect -- however, adding a 'command' to disables the automatic retrigger.
Place the cursor after and press enter. Then accept. Notice that is not suggested.
That monaco repro / editor is really cool
Thanks! The best thing is that you can use the "Monaco Editor Playground" launch config in the VS Code repo to debug the playground example :)
<!-- 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!
Code change:
import { Slugifier } from './slugify'; import { ITextDocument } from './types/textDocument'; import { Disposable } from './util/dispose'; <del> import { stringHash } from './util/hash'; </del> import { WebviewResourceProvider } from './util/resources'; import { isOfScheme, Schemes } from './util/schemes'; import { MdDocumentInfoCache } from './util/workspaceCache';

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/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.68.1 OS Version: Windows 10 Steps to Reproduce: a Markdown file and open "Open Preview to the Side" add line: ! image in preview second line: ! second image shows up. Remove the line above image preview shows 2 images and does not update properly !
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.68.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Still happens in 1.68.1. Updating bug
Does this reproduce in the with all ?
Yes still happens with all extensions disabled
Code change:
private addLinkValidator(md: any): void { const validateLink = md.validateLink; md.validateLink = (link: string) => { <del> // support file:// links </del> return validateLink(link) <del> || isOfScheme(Schemes.file, link) </del> || isOfScheme(Schemes.vscode, link) || isOfScheme(Schemes['vscode-insiders'], link) || /^data:image/.*?;/.test(link);

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.51.1 OS Version: on both Fedora 32 and Linux Mint 20 Steps to Reproduce: clone issuesvscode1400markdownPreviewRootRelativeImg . doesn't display in ! <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes This issue had already occurred in past: In the latest insiders vs-code build - it's not fixed as well.
I took a look at this and found that the issue is that the resource vscode-webview-resource uri is invalid, is missing before I was looking how to fix it but I can't find the place where the gets mapped to a can you give me some code pointers?
here is my quick and dirty fix for this issue:
Start by looking in the markdown link normalizer I believe this is passed the raw image links and tries to transform them into url that VS Code can render in the preview
Thanks and after spending some more time looking at this I think I found a proper fix for it