jiebi/CodeConvo huggingface dataset:
Code change:
private readonly _onDispose = this._register(new Emitter<void>()); readonly onDispose = this._onDispose.event; <del> readonly capabilities = 0; </del> <ins> readonly capabilities = WorkingCopyCapabilities.None; </ins> readonly name = basename(this.resource);

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: head OS Version: n/a This is a bug/inconsistency in the VSC codebase, which is currently obscured because of the specific way the code is written. This wouldn't really matter, but when using a build step that generates files for dependencies, the gets evaluated down to and compilation fails. And overall, it'd be nice for the types to align in a sensible way. Steps to Reproduce: , replace with Expected: compiles fine Actual: there are a number of errors like Property 'getFirstLineText' does not exist on type 'never'. The intersection 'this &amp; IResolvedTextFileEditorModel' was reduced to 'never' because property 'capabilities' has conflicting types in some (2339)TextFileEditorModelIWorkingCopyIResolvedTextFileEditorModelthis.isResolved() is known to be true) says capabilities should be a readonly 2. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Since this seems to concern only you with your specific setup, wanna do a PR to fix this?
I would be more than happy to, but I'm not sure what approach you'd find (in)appropriate. could type in as a number instead of an enum (since checks against it are anyways done via bitwise-and) could change in to actually be 2 instead of 0 (though it seems like you also use 0 for this field in other places like , and somehow TSC doesn't care...) could add a enum value of 0 to , since it seems like that's how you use it. I'm leaning towards approach 3. What are your thoughts?
Yeah I think we can give 3. a try in a PR.
Code change:
"when": "false" } ], <del> "webview/context": [ { "command": "notebook.cellOutput.copy", "when": "webviewId == 'notebook.output' && webviewSection == 'image'" } ] </del> <ins> "webview/context": [ { "command": "notebook.cellOutput.copy", "when": "webviewId == 'notebook.output' && webviewSection == 'image'" } ] </ins> } }, "scripts": {

Related discussion:
text: Type: <bBug</bI have noticed two problems with my vscode-insiders installation which I assume may form one issue. a notebook in nbformat 4.5 is opened, new cells do not receive cell ids, even though this is required by the format spec and is a documented feature of vscode: a new notebook is created, the format is always 4.2. I am not sure whether this is expected. Steps to reproduce: a notebook with jupyterlab or any other way (jupytext etc.), and verify that it has nbformat = 4.5 the notebook in vscode, and generate a new cell, then save. the JSON of the saved notebook - the new cell does not have a cell id. Some additional points which may be of interest The issue persists when all extensions except jupyter/python are disabled. I have recent versions of nbformat etc. installed, but I would assume this is bundled with vscode anyway. The issue also exists on the current pre-release version of the jupyter extension. I haven't found any configuration option which would enable or disable support of notebook formats 4.2 Maybe I have missed a configuration option which I should have set? VS Code version: Code - Insiders 1.84.0-insider (, 2023-10-23T05:33:33.712Z) OS version: Linux x64 6.2.0-35-generic Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (18)</summaryExtensionVersion ------ vscode-neovim0.9.1 vscode-eslint2.4.2 githistory0.6.20 fuzzy-search0.0.3 black-formatter2023.5. python2023.19. vscode-pylance2023.7.40 jupyter2023.10. jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 remote-ssh0.107. remote-ssh-edit0.86.0 remote-explorer0.5. remote-server1.5.
Code change:
"when": "false" } ], <del> "webview/context": [ { "command": "notebook.cellOutput.copy", "when": "webviewId == 'notebook.output' && webviewSection == 'image'" } ] </del> <ins> "webview/context": [ { "command": "notebook.cellOutput.copy", "when": "webviewId == 'notebook.output' && webviewSection == 'image'" } ] </ins> } }, "scripts": {

Related discussion:
text: even-better-toml0.19.2 my-vscode-utils0.0.2 pyexec0.0.1 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thank you for filing this issue and sorry you are running into this. I can replicate this at my end as well. Will look into this.
Code change:
export interface IActiveEditorActions { readonly actions: IToolbarActions; <del> readonly onDidChange: Event<IMenuChangeEvent>; </del> <ins> readonly onDidChange: Event<IMenuChangeEvent | void>; </ins> } export interface IEditorGroup {

Related discussion:
text: Steps: begin with multi tabs showing open an editor hide tab bar actions move to the top close editor open same editor actions are not visible anymore, there is just a "..." <img width="1348" alt="image" src=""
When creating the editor actions we rely on the event to tell us when actions change. However, this event is not set when there is no active pane. In that case we should have a different event trigger the onDidChange event such as onDidChangeActiveEditor for example
Code change:
'./foo', '../foo', '/foo/bar', <del> 'foo/bar' </del> <ins> '/foo/bar+more', 'foo/bar', 'foo/bar+more', </ins> ]; const windowsLinks = [

Related discussion:
text: Issue Type: <bBug</bnew VSCode window new Terminal terminal: terminal: in Cmd and mouse over the two listing name. Only the /tmp/Foo.h will be clickable. won't be because of the . VS Code version: Code 1.43.0 (, 2020-03-09T19:34:44.548Z) OS version: Darwin x64 19.3.0 <!-- generated by issue reporter --
/duplicate
Code change:
*/ getBoundaryScore?(length: number): number; } <del> export class SequenceFromIntArray implements ISequence { constructor(private readonly arr: number[]) { } getElement(offset: number): number { return this.arr[offset]; } get length(): number { return this.arr.length; } } </del>

Related discussion:
text: Diffing the files: original: modified: <img width="1127" alt="image" src="https://user-"It would be better to line up things differently and give preference to having lines with smaller indent be boundary lines. fyi
Very nice idea!! Very valuable example. I can implement this in the experimental diffing algorithm, and soon we can discuss to deprecate the smart diffing algorithm ().
Implemented in the experimental diff algorithm (not smart). Let's try to deprecate the smart diff algorithm in favor of the experimental in the next milestones.
Closing, as this is implemented in the experimental diff algorithm, which is now the default. To verify, try it out in the playground:
Code change:
import { extHostNamedCustomer } from 'vs/workbench/api/common/extHostCustomers'; import { revive } from 'vs/base/common/marshalling'; import { IExtensionService } from 'vs/workbench/services/extensions/common/extensions'; <ins> import { SerializableObjectWithBuffers } from 'vs/workbench/services/extensions/common/proxyIdentifier'; </ins> @extHostNamedCustomer(MainContext.MainThreadCommands) export class MainThreadCommands implements MainThreadCommandsShape {

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:
private didLayout = false; private emptyViews: ISplitViewView<{ top: number; left: number }>[] | undefined; private readonly splitViewDisposables = new DisposableStore(); <del> private centeredLayoutFixedWidth = true; </del> constructor( private container: HTMLElement, private view: IView, <del> public state: CenteredViewState = { ...defaultState } </del> <ins> public state: CenteredViewState = { ...defaultState }, private centeredLayoutFixedWidth: boolean = false </ins> ) { this.container.appendChild(this.view.element); // Make sure to hide the split view overflow like sashes #52892

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.78.0 OS Version: Windows 10 (x64) Steps to Reproduce: "Centered Layout". the editor by independently moving its sashes (holding down Alt). and restart VS Code. The position used to be remembered in previous versions, but starting with version 1.76, the position gets reset on every start. Only the width is being remembered. It's still broken in the current insider build of VS Code 1.78.0.
Do we already know, which commit causes this regression?
I looked through the commits for 1.76.0 and I suspect it was .
Yeah, it is solved for me.
Code change:
resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@25.8.0: version "25.8.0" resolved "https://registry.yarnpkg.com/electron/-/electron-25.8.0.tgz#60c84f1f256924ac5a0aff13276b901b0c43767a" integrity sha512-T3kC1a/3ntSaYMCVVfUUc9v7myPzi6J2GP0Ad/CyfWKDPp054dGyKxb2EEjKnxQQ7wfjsT1JTEdBG04x6ekVBw== </del> <ins> electron@25.8.1: version "25.8.1" resolved "https://registry.yarnpkg.com/electron/-/electron-25.8.1.tgz#092fab5a833db4d9240d4d6f36218cf7ca954f86" integrity sha512-GtcP1nMrROZfFg0+mhyj1hamrHvukfF6of2B/pcWxmWkd5FVY1NJib0tlhiorFZRzQN5Z+APLPr7aMolt7i2AQ== </ins> dependencies: "@electron/get" "^2.0.0" "@types/node" "^18.11.18"

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:
resolved "https://registry.yarnpkg.com/electron-to-chromium/-/electron-to-chromium-1.4.207.tgz#9c3310ebace2952903d05dcaba8abe3a4ed44c01" integrity sha512-piH7MJDJp4rJCduWbVvmUd59AUne1AFBJ8JaRQvk0KzNTSUnZrVXHCZc+eg+CGE4OujkcLJznhGKD6tuAshj5Q== <del> electron@25.8.0: version "25.8.0" resolved "https://registry.yarnpkg.com/electron/-/electron-25.8.0.tgz#60c84f1f256924ac5a0aff13276b901b0c43767a" integrity sha512-T3kC1a/3ntSaYMCVVfUUc9v7myPzi6J2GP0Ad/CyfWKDPp054dGyKxb2EEjKnxQQ7wfjsT1JTEdBG04x6ekVBw== </del> <ins> electron@25.8.1: version "25.8.1" resolved "https://registry.yarnpkg.com/electron/-/electron-25.8.1.tgz#092fab5a833db4d9240d4d6f36218cf7ca954f86" integrity sha512-GtcP1nMrROZfFg0+mhyj1hamrHvukfF6of2B/pcWxmWkd5FVY1NJib0tlhiorFZRzQN5Z+APLPr7aMolt7i2AQ== </ins> dependencies: "@electron/get" "^2.0.0" "@types/node" "^18.11.18"

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:
applyZoom(webFrame.getZoomLevel() - 1); } }; <del> } </del>  No newline at end of file <ins> } </ins>

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:
'navigation', shouldInlineGroup ); <ins> } else { // If there is no active pane in the group (it's the last group and it's empty) // Trigger the change event when the active editor changes const _onDidChange = new Emitter<void>(); onDidChange = _onDidChange.event; disposables.add(this.onDidActiveEditorChange(() => _onDidChange.fire())); </ins> } return { actions: { primary, secondary }, onDidChange };

Related discussion:
text: Steps: begin with multi tabs showing open an editor hide tab bar actions move to the top close editor open same editor actions are not visible anymore, there is just a "..." <img width="1348" alt="image" src=""
When creating the editor actions we rely on the event to tell us when actions change. However, this event is not set when there is no active pane. In that case we should have a different event trigger the onDidChange event such as onDidChangeActiveEditor for example
Code change:
import { IChatCommandButton, IChatContentReference, IChatFollowup, IChatProgressMessage, IChatResponseErrorDetails, IChatResponseProgressFileTreeData, IChatUsedContext, InteractiveSessionVoteDirection } from 'vs/workbench/contrib/chat/common/chatService'; import { countWords } from 'vs/workbench/contrib/chat/common/chatWordCounter'; import { CodeBlockModelCollection } from './codeBlockModelCollection'; <ins> import { IMarkdownString } from 'vs/base/common/htmlContent'; </ins> export function isRequestVM(item: unknown): item is IChatRequestViewModel { return !!item && typeof item === 'object' && 'message' in item;

Related discussion:
text: Steps: extension that registers a document and a document range formatting provider open a test workspace that activates the extension and trigger a range format. You get:
Code change:
return; } <ins> const next = keybindingService.lookupKeybinding(AccessibleDiffViewerNext.id)?.getAriaLabel(); const previous = keybindingService.lookupKeybinding(AccessibleDiffViewerPrev.id)?.getAriaLabel(); let switchSides; const switchSidesKb = keybindingService.lookupKeybinding('diffEditor.switchSide')?.getAriaLabel(); if (switchSidesKb) { switchSides = localize('msg3', "Run the command Diff Editor: Switch Side ({0}) to toggle between the original and modified editors.", switchSidesKb); } else { switchSides = localize('switchSidesNoKb', "Run the command Diff Editor: Switch Side, which is currently not triggerable via keybinding, to toggle between the original and modified editors."); } </ins> const keys = ['accessibility.signals.diffLineDeleted', 'accessibility.signals.diffLineInserted', 'accessibility.signals.diffLineModified']; const content = [ localize('msg1', "You are in a diff editor."), localize('msg2', "View the next ({0}) or previous ({1}) diff in diff review mode, which is optimized for screen readers.", next, previous), <del> localize('msg3', "To control which accessibility signals should be played, the following settings can be configured: {0}.", keys.join(', ')), </del> <ins> switchSides, localize('msg4', "To control which accessibility signals should be played, the following settings can be configured: {0}.", keys.join(', ')), </ins> ]; const commentCommandInfo = getCommentCommandInfo(keybindingService, contextKeyService, codeEditor); if (commentCommandInfo) {

Related discussion:
text: mentioned that the diff editor experience is a little confusing because we don't explicitly state that the current editor is the modified one vs the original editor. AFAICT, there's also no way to jump between the original and modified ones. Is this correct? & I'd appreciate your thoughts here. Edit: action items: [ ] add info in help dialog about switch sides command [ ] get accessibility signals to work in original editor
There is the Diff Editor: Switch Sides command that moves focus to the other side. Maybe the wording could be improved. So not sure what needs to be done here? Feels like similar to the other issue you created about missing clarity in announcements on original vs modified.
Yes, I was unaware of that command. We should include it in the diff editor help dialog and include a default keybinding for when in screen reader mode as that's definitely something users would want to do IMO.
pointed out this should maybe be a tab stop if possible
I have the following keybinding, but there was no noticeable change (at least to from a screen reader user's standpoint) after switching into the other side. :
could you tell there was a focus change at all? Is there also no difference if you run the command vs use the keybinding?
Audio cues do not work when I'm navigating in the original editor. !