jiebi/CodeConvo huggingface dataset:
Change:
import * as dom from 'vs/base/browser/dom'; import { StandardWheelEvent, IMouseWheelEvent } from 'vs/base/browser/mouseEvent'; import { TimeoutTimer } from 'vs/base/common/async'; <del> import { Disposable } from 'vs/base/common/lifecycle'; </del> <ins> import { Disposable, IDisposable } from 'vs/base/common/lifecycle'; </ins> import * as platform from 'vs/base/common/platform'; import { HitTestContext, MouseTarget, MouseTargetFactory, PointerHandlerLastRenderData } from 'vs/editor/browser/controller/mouseTarget'; import { IMouseTarget, IMouseTargetViewZoneData, MouseTargetType } from 'vs/editor/browser/editorBrowser';

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: 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.63.0 OS Version: Windows 11 Steps to Reproduce: a file where breakpoints can be set around the edge of the editor, in and out of the margin until the breakpoint stays even though the mouse is outside of the editor (see GIF below). ! This is important to me because I am using margin decorations in Monaco and running into the same issue there. Internally the event isn't triggered, so the decorations aren't removed. It seems to be specific to decorations in the glyph margin, as without these (e.g. line decorations) it doesn't seem to reproduce.
I can reproduce when moving the mouse quickly. I find it interesting that also the scrollbars suffer form the same problem (the scrollbars listen independently to ). I've also tried locally to replace with the somewhat more modern and I could still reproduce. Basically the browser simply forgets soemtiems to send us a or a event: <img width="538" alt="image" src="https://user-"
Change:
this.language = language; } <del> if (diagnostics.length === 0) { const existing = this._diagnostics.get(kind); if (!existing || existing && existing.length === 0) { // No need to update return false; } </del> <ins> const existing = this._diagnostics.get(kind); if (arrays.equals(existing || arrays.empty, diagnostics, diagnosticsEquals)) { // No need to update return false; </ins> } this._diagnostics.set(kind, diagnostics);

Discussion:
! Open Put the cursor on a tslint warning Get a lightbulb with quick fix suggestions, but it blinks Seems to be related to cursor blink I think this is a regression from 1.34 but can't be sure because it doesn't happen totally consistently.
Repos for me in that specific file around line 90. Weird Looks like something is causing loops of refactoring requests
Looks like a real js/ts bug but not a regression. Too risky to fix this iteration as it involves scheduling and how we manage errors for TypeScript
The cause: Code requests diagnostics (it doesn't matter why, but it has to happen in a state where there is a pending request against the TSServer for the current file) our js/ts refactoring provider, we tell TS server to cancel its current work computing diagnostics (because we want to service the code actions request as soon as possible) we cancel the current request to the tsserver, trigger a new request, and then reschedules a new request with the current file in it refactor response is returned so we show the lightbulb then we get back part of the geterr response (but not the full response). This partial response updates diagnostics in the current file after a short delay (even if they have not changed) diagnostic change cause VS code to request code actions again while we still have pending diagnostics for the current file to step 1 I don't understand why this doesn't happen all the time
Change:
enabled: prop.format === 'color-hex', isValid: ((value: string) => Color.Format.CSS.parseHex(value)), message: nls.localize('validations.colorFormat', "Invalid color format. Use #RGB, #RGBA, #RRGGBB or #RRGGBBAA.") <del> } </del> <ins> }, { enabled: prop.format === 'uri' || prop.format === 'uri-reference', isValid: ((value: string) => !!value.length), message: nls.localize('validations.uriEmpty', "URI expected.") }, { enabled: prop.format === 'uri' || prop.format === 'uri-reference', isValid: ((value: string) => uriRegex.test(value)), message: nls.localize('validations.uriMissing', "URI is expected.") }, { enabled: prop.format === 'uri', isValid: ((value: string) => { const matches = value.match(uriRegex); return !!(matches && matches[2]); }), message: nls.localize('validations.uriSchemeMissing', "URI with a scheme is expected.") }, </ins> ].filter(validation => validation.enabled); }

Discussion:
Found this issue while trying to set 's format to uri (or uri-reference), in order to fix <!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.42.0-insider () OS Version: Mac OS 10.14.6 Steps to Reproduce: a "mysetting" setting define "format":"uri" (as documented in ) settings in UI, write then delete some value, no error is shown , see that has a warning: <img width="1155" alt="Screen Shot 2020-01-15 at 7 44 33 PM" src="https://user-"The validation error should be displayed in the UI too (as it does when using a validation pattern) <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Maybe
I guess we are missing that validation, also, the type of that setting should be if the default is "null".
I can try working on this. Any code pointers, though? Not sure where to look.
See for where these validations for the settings editor live. You need to figure out what validation the json language server does for . I assume that lives somewhere in but I don't know where. I can help you if you can't find it.
Verifier: the extension and search in the settings editor different values in the textbox that shows up. The empty string should not be accepted, and a string such as should not be accepted. However, , , and should be accepted.
This bug has been fixed in to the latest release of ! you can help us out by confirming things are working as expected in the latest Insiders release. If things look good, please leave a comment with the text to let us know. If not, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Change:
-webkit-text-size-adjust: 100%; color: var(--vscode-editor-foreground); background-color: var(--vscode-editor-background); <ins> overflow-wrap: initial; </ins> } .monaco-editor-background { background-color: var(--vscode-editor-background);

Discussion:
This is caused by some fonts, where the character width is a fractional number (probably also related to DPI settings): ! This surfaced after I removed any margin around the line numbers to make the diff view more compact. I guess this is ultimately caused by the use of instead of here: ...however, at the moment, this is only surfaced in the diff editor inside the inline chat, because of this rule that is inherited to child elements:
Change:
"private": true, "dependencies": { "applicationinsights": "1.0.8", <del> "chokidar": "3.4.3", </del> <ins> "chokidar": "3.5.0", </ins> "cookie": "^0.4.0", "graceful-fs": "4.2.3", "http-proxy-agent": "^2.1.0",

Discussion:
Steps to Reproduce: on Apple SI a folder in devtools:
Related failing unit test:
Chokidar v3.5.0 was just released that takes in fsevents universal build , we can update to it.
yep this required compiling fsevents as universal binary
Change:
this._onLinksReady.fire(this); }); <del> // TODO: This should be an optional addon this._xtermTypeAheadAddon = this._register(this._instantiationService.createInstance(TypeAheadAddon, this._processManager, this._configHelper)); xterm.raw.loadAddon(this._xtermTypeAheadAddon); </del> <ins> this._loadTypeAheadAddon(xterm); this._configurationService.onDidChangeConfiguration(e => { if (e.affectsConfiguration(TerminalSettingId.LocalEchoEnabled)) { this._loadTypeAheadAddon(xterm); } }); </ins> this._pathService.userHome().then(userHome => { this._userHome = userHome.fsPath; }); return xterm; } <ins> private _loadTypeAheadAddon(xterm: XtermTerminal): void { const enabled = this._configHelper.config.localEchoEnabled; const isRemote = !!this.remoteAuthority; if (enabled === 'off' || enabled === 'auto' && !isRemote) { return this._xtermTypeAheadAddon?.dispose(); } if (this._xtermTypeAheadAddon) { return; } if (enabled === 'on' || (enabled === 'auto' && isRemote)) { this._xtermTypeAheadAddon = this._register(this._instantiationService.createInstance(TypeAheadAddon, this._processManager, this._configHelper)); xterm.raw.loadAddon(this._xtermTypeAheadAddon); } } </ins> detachFromElement(): void { this._wrapperElement?.remove(); this._container = undefined;

Discussion:
There are too many issues with local echo and can really degrade the experience right now for local workspaces. We should add an on/off/auto setting where auto is disabled in local workspaces, so opt-in ssh in local terminal support is there.
what steps would we take to verify? Looks like there's a new setting?
I tested the setting
Change:
} else if (v && 'notebookEditor' in v) { const notebookEditorId = this._extHostNotebook.getIdByEditor(v.notebookEditor); if (notebookEditorId === undefined) { <del> throw new Error(`Cannot invoke 'notebook.selectKernel' for unrecognized notebook editor ${v.notebookEditor.document.uri.toString()}`); </del> <ins> throw new Error(`Cannot invoke 'notebook.selectKernel' for unrecognized notebook editor ${v.notebookEditor.notebook.uri.toString()}`); </ins> } return { notebookEditorId }; }

Discussion:
The has been finalized with VS Code 1.68 (). If your extension was using the proposal, you should now switch to the finalized version of this API. In the majority of cases, this switch is as simple as: your extension to target VS Code in the new from your list of enabled API proposal. However there are few small bumps to be aware of: has been renamed . Please make sure to switch over to the new property name as part of this migrationWe did not finalize the version of that takes a uri. Instead you can use Here's a list of all current consumers of the old API proposal: [x] ms-vsliveshare.vsliveshare — [X] ms- — [x] Dot net interactive — [x] GitHub.codespaces — [x] ms- — If you own one of these extensions, please migrate to the finalized notebook editor API. Let me know once the new version of your extension is published and I will remove your extension from the list of api consumers
I am actually fine in ESLint. The dependency was because of notebook support in LSP and LSP already converted to the final version for the 8.x release of the LSP libs.
Thank you everyone who's checked off their extension so far! If you have, I plan to remove your extension from the list of API consumers in July. This will only start effecting the insiders builds of VS Code at first, but please let me know if you notice any issues
I'm working on the change for Codespaces and expect it to be in our next extension release (1.10.0) in a few days. I'll reply back once it's on the marketplace.
We just published GitHub Codespaces 1.10.0 with this change, so you should be able to remove our extension from the list of proposed API consumers.
Change:
// Check for invalid file name. if (names.some(folderName => !pathService.hasValidBasename(item.resource, os, folderName))) { <ins> // Escape * characters const escapedName = name.replace(/*/g, '*'); </ins> return { <del> content: nls.localize('invalidFileNameError', "The name **{0}** is not valid as a file or folder name. Please choose a different name.", trimLongName(name)), </del> <ins> content: nls.localize('invalidFileNameError', "The name **{0}** is not valid as a file or folder name. Please choose a different name.", trimLongName(escapedName)), </ins> severity: Severity.Error }; }

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --! Does this issue occur when all extensions are disabled?: 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.67.2 OS Version: Windows 11 10.0. Build Steps to Reproduce: the new folder button in the explorer panel; the new folder "**", without the quotation marks; text from red dialog box under the folder name is now bold, except for "The name ".
Probably because of markdown
The text box doesn't turn red or bold, so considering that a success
The text box should still be red saying it's an invalid file name on windows. Just the text should not become bold
I think the box is supposed to be red
the box did not turn red for me with a folder name of
Was this on windows?
no it's working for me on windows. it wasn't working on mac
** just happens to be a valid file name on macOS , thanks for verifying!
Change:
}, dispose: () => { mouseOverDomEmitter.dispose(); <ins> mouseLeaveEmitter.dispose(); mouseDownEmitter.dispose(); mouseUpEmitter.dispose(); </ins> focusDomEmitter.dispose(); hideHover(true, true); }

Discussion:
! It's those 3 options that don't work, until there are multiple shells running. Once you have two or more shells, those options start working, as below I'm showing me renaming successfully the 2nd shell: ! Originally posted by in
I think related to this
PR fixing it
moving the issue with to this issue as it's not a recent regression
Change:
registerEditorAction(PageDownHoverAction); registerEditorAction(GoToTopHoverAction); registerEditorAction(GoToBottomHoverAction); <del> registerEditorAction(EscapeFocusHoverAction); </del> HoverParticipantRegistry.register(MarkdownHoverParticipant); HoverParticipantRegistry.register(MarkerHoverParticipant);

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: 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 Insiders Version: VS Code Version: OS Version: Ubuntu 22.04.2 LTS Steps to Reproduce: This issue is identical to which was supposedly fixed by . I do not have a windows machine atm, so I cannot test if this is exclusively an issue with the snap-installed version of vscode, but I highly doubt it is. does give focus back to editor, but that's just a workaround.
Hi thanks for filing the issue. It appears this is a regression from the previous work done on making the hover resizable. A fix will be made.
Change:
if (!isMacintosh) { return super.minimumHeight; } <del> return (this.isCommandCenterVisible ? 35 : this.getMacTitlebarSize()) / getZoomFactor(); </del> <ins> return (this.isCommandCenterVisible ? 35 : this.getMacTitlebarSize()) / (this.useCounterZoom ? getZoomFactor() : 1); </ins> } override get maximumHeight(): number { return this.minimumHeight; }

Discussion:
Code mac, have custom title bar in bar is not zooming in like the rest of the workbench To make the custom title bar accessible it needs to be zoomable. fyi
in general we've never done this. in fact on Windows we don't zoom in if the menubar is not present since the native title bar would not zoom. its up to the OS to decide the scale of the title bar. however, I do see a case to update the conditions if the new command center is present. what are your thoughts? further thing to consider. we can zoom in, but zooming out (below 1 zoom level) is not an option because the window controls have a minimum size.
I agree with you, and as we put more VS Code items in the title area I see a clear case to support zoom. Since the title area will feel more and more like an integral part of VS Code - and thus it should behave like the rest. Not being able to zoom out is fine imho. I feel that is the corner case. might also have thoughts, since we both noticed this bug when I was demoing the title bar search yesterday.
I think we need to work with Electron to also then zoom the native window controls, otherwise it looks like this: !
we can zoom in the controls, we just cannot zoom out, so that can be updated though the black bar is a separate issue that makes it look worse
1.67.2 TitleBar ! 1.68 TitleBar ! The new version is so small that it's hard to click
Agreed. Noticed this too after updating to v1.68. I use zoom : -1 but the title bar is still big and not zoomed out like the rest of the content
I have verified that the custom title bar can now we zoomable - thanks for that As you said zoom out is not supported which is fine, however on zoom out, the title bar does not change size but gets blurry. Like the browser anti aliasing rendering gets broken. Let me know if you would like me to file a new issue for this.
hmm yes, probably the way we implement counter zooming gives us this behavior, I don't think this is new however, nor do I think there is an easy fix for that. Would you mind verifying on stable for your machine?

If it is new, I would like a separate issue to investigate.
I can reproduce on stable. So I will not file an issue. If you still need one just let me know. Thanks!
Change:
private _createInset(webviewService: IWebviewService, content: string) { const workspaceFolders = this.contextService.getWorkspace().folders.map(x => x.uri); <del> const notebookDir = dirname(this.documentUri); </del> <ins> const notebookDir = this.getNotebookBaseUri(); </ins> this.localResourceRootsCache = [ ...this.notebookService.getNotebookProviderResourceRoots(),

Discussion:
When converting a jupyter notebooks to a python code file, images no longer load. VS Code version: 1.60.0 Jupyter Extension version (available under the Extensions sidebar): v2021.8. Python Extension version (available under the Extensions sidebar): v2021.9. OS (Windows Linux distro) and version: Linux 5.8.0-59-generic 20.04.1-Ubuntu Python and/or Anaconda version: 3.9.6 Type of virtual environment used (N/A ...): conda Jupyter server running: Local a python file with the following code a random local image the cell The image should load After opening the dev tools, it seems that vscode is trying to load https://vscode- instead of the local file, using an online image from the web does work, unfortunetly local files does not even when using the protocol.
I can replicate this, for some reason images are not loaded when in interactive window.
hi, could you get any updates?
<!-- 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!
Still not working, the local images are not loading. Version: 1.71.0-insider Commit: Date: 2022-08-24T05:18:31.474Z Electron: 19.0.12 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Linux x64 5.19.3--generic Sandboxed: Yes
Works fine for me: ! Do you have a folder open with both the notebook and image in it?
Thanks for the clarification, yes it only works when the folder is opened. For comparison, if I create a .ipynb file, the images are loaded even though no folder is opened.
Reopening based on the submitter's comment
I believe this is working as intended. The OP confirmed it works when a folder is open.

If you don't have a folder open though, we don't know where the load images from You could argue that in the no folder case we should then use the file's directory, but the interactive window is not linked to a single python file so I'm wary of trying to make this too clever. Better to keep it consistent IMO
Change:
processes.sanitizeProcessEnvironment(env); assert.strictEqual(env['FOO'], 'bar'); assert.strictEqual(env['VSCODE_SHELL_LOGIN'], '1'); <del> assert.strictEqual(Object.keys(env).length, 2); </del> <ins> assert.strictEqual(env['VSCODE_PORTABLE'], '3'); assert.strictEqual(Object.keys(env).length, 3); </ins> }); });

Discussion:
Does this issue occur when all extensions are disabled?: 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.74.2 OS Version: Arch with Linux v6.1.3 Steps to Reproduce: VS Code in portable mode (VSCODEPORTABLE env var set to a directory) a file in the instance by typing in the integrated terminal. Code opens a new window rather than opening the file as a tab, and the new window reads userdata from instead of "$VSCODEPORTABLE". Possible solution: I investigated and noticed that the integrated terminal in VS Code reads the env var as unset even if it is set by the OS. As a workaround, I have this to my config, and it works:
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.74.3. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Happens on the latest version as well: !
Oh if we just need set for this to work I can remove that from the env sanitization.
<!-- 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!