jiebi/CodeConvo huggingface dataset:
Change:
import { ISymbolQuickPickItem, SymbolsQuickAccessProvider } from '../../../search/browser/symbolsQuickAccess.js'; import { IEditorService } from '../../../../services/editor/common/editorService.js'; import { IClipboardService } from '../../../../../platform/clipboard/common/clipboardService.js'; <del> import { isImage } from '../chatImagePaste.js'; import { hash } from '../../../../../base/common/hash.js'; </del> <ins> import { imageToHash, isImage } from '../chatImagePaste.js'; </ins> import { IConfigurationService } from '../../../../../platform/configuration/common/configuration.js'; import { ActiveEditorContext } from '../../../../common/contextkeys.js';

Discussion:
Testing a large image () it into chat window freezes for a few seconds Seems we spent in the !
cc. is there a compromise on what we hash for the ID? ie, maybe half of the bytes instead of the full thing, or something of the sort, since ATM we are just hashing the entire received
It looks like the function is trying to hash the Uint8Array naively as an object (hashing each key and value for each element in the array) which is going to be extraordinarily slow. should complete in millisecond(s) :)
should our detect if it's web and if crypto is available and use that if so? I can see this happening again.
Yea, I think having it check for typed arrays and arraybuffers would make sense. Unfortunately is sync and webcrypto is async, however, so it would not be a drop-in replacement.
perhaps we could have a signature like to catch at compile time and redirect that use to the async version in ?
Change:
const result: MarkerStatistics = { errors: 0, warnings: 0, infos: 0, unknowns: 0 }; // TODO this is a hack <del> if (resource.scheme === Schemas.inMemory || resource.scheme === Schemas.walkThrough || resource.scheme === Schemas.walkThroughSnippet || resource.scheme === Schemas.vscodeSourceControl) { </del> <ins> if (unsupportedSchemas.has(resource.scheme)) { </ins> return result; }

Discussion:
Testing <img width="1617" alt="image" src="https://user-"
I can't get squiggles to show up for the commit input box at all, even after following the steps from the linked TPI. What are some steps to verify this, or maybe someone else can verify?
Thanks Reopening the bug as the fix for this has introduced a regression.
Checked in a better fix for this issue. Should be included in tomorrow's Insiders release (2022-08-26).
closedWith
Verified, but the actions in the hover don't do anything: !
Thanks I have filed to track the issue with the actions.
Change:
} private initialize(): TPromise<[IColorTheme, IFileIconTheme]> { <ins> let detectHCThemeSetting = this.configurationService.getValue<boolean>(DETECT_HC_SETTING); let colorThemeSetting: string; if (this.windowService.getConfiguration().highContrast && detectHCThemeSetting) { colorThemeSetting = HC_THEME_ID; } else { colorThemeSetting = this.configurationService.getValue<string>(COLOR_THEME_SETTING); } </ins> <del> let colorThemeSetting = this.configurationService.getValue<string>(COLOR_THEME_SETTING); </del> let iconThemeSetting = this.configurationService.getValue<string>(ICON_THEME_SETTING) || ''; return Promise.join([

Discussion:
(Moved from internal Windows Feedback bug database) on High Contrast Black VS Code that inside of the frame, the text shows up normally (not in high contrast). This is an accessibility issue
The current workaround is to manually switch VS Code to the High Contrast Theme via
is there electron API to detect high contrast mode automatically?
Yeah I thought we detect high contrast on Windows, I have to check.
I see that the theme is correctly passed on to the renderer () but then is reset back to the previous one (e.g. ). Can you check why the theme is not applied? To reproduce: enable HC theme on Windows start VS Code expect it to show in HC theme
The hc theme needs to be set in the settings or on the theme service, like (). This will trigger all theming participants that then ally the theming and generate the css rules. Setting the class name just helps with the initial window appearance.
it looks like you removed that code that handles high contrast on Windows and never it back to the renderer ()? I created to prefer the HC theme if we detect high contrast mode. It is a bit ugly though because the settings are still containing the previous theme, not sure we should just blindly overwrite it because the HC theme on Windows could be a temporary thing.
Change:
_renderer: { _renderLayers?: any[]; }; <del> _onIntersectionChange: any; </del> <ins> _handleIntersectionChange: any; </ins> }; }

Discussion:
latest insiders dev tools console :bug: see several of these messages:
called here non-existent in the repo
Think this is fine to wait until November as I don't see this in dev tools - has this repro'd for you?
Yeah I see it as soon as I open the terminal panel. It's an ugly dev tools message but agree it can probably wait
Change:
// scope: ConfigurationScope.APPLICATION }, [TerminalSettingId.StickyScrollMaxLineCount]: { <del> markdownDescription: localize('terminal.integrated.stickyScroll.maxLineCount', "Defines the maximum number of sticky lines to show."), </del> <ins> markdownDescription: localize('terminal.integrated.stickyScroll.maxLineCount', "Defines the maximum number of sticky lines to show. Sticky scroll lines will never exceed 40% of the viewport regardless of this setting."), </ins> type: 'number', default: 5, minimum: 1,

Discussion:
Testing I ran the following command which is a powershell command that spans 8 lines. In this case sticky scroll can fill the entire terminal. One thing we do for sticky scroll in the tree is we allow sticky scroll to take a maximum of 40% of the view height. If the widget takes more than 40% of the height, we start dropping some of the sticky lines. In that case you could possibly have a at the end of the last line to indicate to the user that there is more to the command than can be shown. powershell command: (is new line) used setting !
I was a little torn on this, I was thinking if a user says they want 10 lines then maybe we should respect that (up a maximum of rows - 1 which isn't the case now). I see there is some logic here in the editor: ! Though it only updates on scroll, not resize: ! Do you also use a max of 40% there?
Your case might be a bit different to the tree. Trees appear in many different locations. One tree might fill the entire height of the editor in one view and another tree view might be much smaller. This would lead the user to have a large max sticky item value to be able to see many nodes in the large tree but he would probably not want it to fill the entire view in the smaller tree view cases. This is maybe a bit different to the terminal where a users usually only has one terminal. I think you should at least guarantee that one line of the terminal is visible.
Hey we do not have such a logic in the editor sticky scroll although it is a very interesting idea and it may be worthwhile to look into it.
Change:
"contributes": { "languages": [{ "id": "html", <del> "extensions": [ ".html", ".htm", ".shtml", ".mdoc", ".jsp", ".asp", ".aspx", ".jshtm" ], </del> <ins> "extensions": [ ".html", ".htm", ".shtml", ".xhtml", ".mdoc", ".jsp", ".asp", ".aspx", ".jshtm" ], </ins> "aliases": [ "HTML", "htm", "html", "xhtml" ], "mimetypes": ["text/html", "text/x-jshtm", "text/template", "text/ng-template"] }],

Discussion:
By default, there appears to be no syntax highlighting for .xhtml files.
is this available in the current release? There was an update recently but it doesn't seem to include this (guessing it'll be in the next update?).
it's in the insiders build, not yet in stable.
Change:
if (jsFlags) { app.commandLine.appendSwitch('--js-flags', jsFlags); } <del> // Disable smooth scrolling for Webviews if (cliArgs['disable-smooth-scrolling']) { app.commandLine.appendSwitch('disable-smooth-scrolling'); } </del> } /**

Discussion:
I am a bit confused about this change, isn't it that command line arguments are being passed to Chrome/Electron anyway? Why is this needed? Originally posted by in
Would you like to submit a PR that reverts the original PR?
Change:
if (this.titleBarStyle !== 'native' && this.layoutControls && event.affectsConfiguration('workbench.layoutControl.enabled')) { this.layoutControls.classList.toggle('show-layout-control', this.layoutControlEnabled); <ins> this._onDidChange.fire(undefined); </ins> } if (event.affectsConfiguration(TitlebarPart.configCommandCenter)) {

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:
// Test file operations that are common across platforms. Used for test infra, namely snapshot tests Object.assign(globalThis, { <ins> __analyzeSnapshotInTests: takeSnapshotAndCountClasses, </ins> __readFileInTests: (/** @type {string} */ path) => fs.promises.readFile(path, 'utf-8'), __writeFileInTests: (/** @type {string} */ path, /** @type {BufferEncoding} */ contents) => fs.promises.writeFile(path, contents), __readDirInTests: (/** @type {string} */ path) => fs.promises.readdir(path),

Discussion:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Currently we are manually hunting down memory leaks through Dev Tools. For some areas/components (e.g., notebook), this even needs to be done repeatedly. It would be helpful if we can capture the memory snapshots in CI and write some queries against the snapshot to analyze if there is any potential leaks. A typical manual memory leak analysis for notebook Setup Open OSS Open notebook document A Open notebook document B Close both notebook documents Open Dev Tools, take a heap snapshot Search object, there should be none Search object, there should be none Search object, there should not be more than one (the editor group still holds a reference to the last editor) ! cc
The dev tools also show how an object is leaked, we could analyze the dependencies tree and figure out who is the "culprit"
would be a good API for CI use case on desktop to capture from any non-sandboxed process (Main, Utility - Ext Host, Shared Process, Pty Agent) embedding V8 without using external CDP calls. In the case of sandboxed render process, prefer
I find this topic super interesting as well! I have a prototype project that tries to find memory leaks by looking for leaking event listeners. In the screencast, the event listener count increases from 1175 to 1206 which indicates that there might be a memory leak when opening and closing a notebook editor. The project is in the early phases and in the future I'm hoping to display more detailed output for the event listeners as well as making the tests less flaky. (sorry if I'm interrupting the discussion. I'm hoping that perhaps this could be useful for you)
Change:
resolved "https://registry.yarnpkg.com/fast-plist/-/fast-plist-0.1.2.tgz#a45aff345196006d406ca6cdcd05f69051ef35b8" integrity sha1-pFr/NFGWAG1AbKbNzQX2kFHvNbg= <del> typescript@4.2.2: version "4.2.2" resolved "https://registry.yarnpkg.com/typescript/-/typescript-4.2.2.tgz#1450f020618f872db0ea17317d16d8da8ddb8c4c" integrity sha512-tbb+NVrLfnsJy3M59lsDgrzWIflR4d4TIUjz+heUnHZwdF7YsrMTKoRERiIvI2lvBG95dfpLxB21WZhys1bgaQ== </del> <ins> typescript@4.2.3: version "4.2.3" resolved "https://registry.yarnpkg.com/typescript/-/typescript-4.2.3.tgz#39062d8019912d43726298f09493d598048c1ce3" integrity sha512-qOcYwxaByStAWrBf4x0fibwZvMRG+r4cQoTjbPtUlrWjBHbmCAww1i448U0GJ+3cNNEtebDteo/cHOR3xJ4wEw== </ins> vscode-grammar-updater@^1.0.3: version "1.0.3"

Discussion:
Tracks bundling TS 4.2.3 with VS Code. This includes a
Should be in recovery and in main now
Change:
*  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <ins> import { RunOnceScheduler } from 'vs/base/common/async'; </ins> import { Emitter, Event } from 'vs/base/common/event'; import { IJSONSchema, IJSONSchemaMap } from 'vs/base/common/jsonSchema'; import { Disposable, IDisposable } from 'vs/base/common/lifecycle';

Discussion:
a repo in :bug: see this !
This is expected if the repo that you open has tasks that run on . Could you pls provide me with a repo for which this happens that doesn't have those?
seeing this dialog when I just open a folder, so wondering if something with workspace trust has changed recently. No changes with tasks recently could explain this. !
Doesn't repro in , repros in : Bad: Good:
found these task PRs in that time frame: ,
found it also happens in an empty window on desktop
Still seeing this in (and also RemoteHub on desktop) with the changes in !
This is coming from -here. perhaps we don't want to do that for the or only do that in trusted workspaces? !
Change:
const isDir = type === vscode.FileType.Directory; yield { label: isDir ? name + '/' : name, <del> insertText: isDir ? encodeURIComponent(name) + '/' : encodeURIComponent(name), </del> <ins> insertText: (context.skipEncoding ? name : encodeURIComponent(name)) + (isDir ? '/' : ''), </ins> kind: isDir ? vscode.CompletionItemKind.Folder : vscode.CompletionItemKind.File, range: { inserting: insertRange,

Discussion:
Issue Type: <bBug</bTrigger path suggestions inside a markdown link that uses angle brackets: Bug No suggestions show up VS Code version: Code - Insiders 1.69.0-insider (Universal) (, 2022-06-17T05:16:27.373Z) OS version: Darwin x64 21.5.0 Restricted Mode: No <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Relevant code:
So I'm new to this project. Do I ask if I can be assigned this bug? Or is it whoever submits an solution first makes the pull request?
You can ask, I am currently working on this now - but you can try as well.
Alright thanks. So in general I can just work on a problem that catches my attention and ask/answer questions when appropriate?
Yes pretty much, you can work on any problem or issue that you would like.
What specifically is the bug here? Is the desired behavior where when you type a list of path links should appear?
Yes, it should work the same way it does if you remove the from the link One extra note: spaces should not be encoded inside links so for extra points make accepting a file suggestion with spaces in the name inserts a real space instead of
How do I recompile typescript files so vscode reflects the changes I made? Is it or ?
Is this the behavior you were looking for?
Change:
configurationService = new TestConfigurationService(); instantiationService.stub(IConfigurationService, configurationService); <ins> instantiationService.set(IProductService, TestProductService); </ins> xterm = new Terminal({ allowProposedApi: true, cols: 80, rows: 30 }); detector = instantiationService.createInstance(TerminalWordLinkDetector, xterm);

Discussion:
Type: <bBug</bContext I want to use vscode-URLs to directly drop into a debugging session. My script can be found at Expected behavior When cmd-clicking this link from inside VSCode, I would expect to be dropped into the debugging session <img width="1287" alt="Screenshot 2022-08-22 at 10 25 59" src="https://user-"Actual behavior Instead, the link gets opened in VS Code's search bar <img width="904" alt="Screenshot 2022-08-22 at 10 27 17" src="https://user-"Additional information I am sure the link itself is fine, because when I copy it from the console and paste it into Chrome's address bar, then VSCode opens my debugging session as expected. Also see VS Code version: Code 1.70.2 (, 2022-08-16T05:36:37.829Z) OS version: Darwin x64 21.6.0 Modes: Remote OS version: Linux x64 5.15.0-30-generic Remote OS version: Linux x64 5.15.0-30-generic <details<summarySystem Info</summary </details<details<summaryExtensions (7)</summaryExtensionVersion ------ better-cpp-syntax1.15.19 jupyter-keymap1.0.0 remote-ssh0.84.0 remote-ssh-edit0.80.0 llvm0.1.1 vscode-clangd0.1.21 vscode-lldb1.7.4 </details<!-- generated by issue reporter --
since the url would need to open a JS/browser debug session, would the JavaScript Debugger Companion Extension be of help here?
This is debugging with lldb, so it's not in the domain of js-debug
This is a request to essentially hook up the terminal link detector to whatever handles external custom protocol links. We may be able to just add vscode:// and vscode-insiders:// to the uri detection? This may need changes in the editor's link detector
Change:
"description": "Extension to add task support for npm scripts.", "displayName": "NPM support for VS Code", "workspaceTrust": "This extension executes tasks, which require trust to run.", <ins> "virtualWorkspaces": "Functionality that requires running the 'npm' command is not available in virtual workspaces.", </ins> "config.npm.autoDetect": "Controls whether npm scripts should be automatically detected.", "config.npm.runSilent": "Run npm commands with the `--silent` option.", "config.npm.packageManager": "The package manager used to run scripts.",

Discussion:
and trust the workspace to Show Running Extensions from the extensions pane :bug: See that npm extension is activated even though it declares in its , which should disable it in all virtual workspaces !
Virtual workspace check is only considered in Desktop. In web all extensions those are web enabled are enabled irrespective of virtual workspace.
Can I ask why this is the case? The npm extension activates eagerly due to when opening a repository containing a file (e.g. extensions). I don't need this extension and today would need to manually disable it.
Virtual workspace support is only for desktop clients. In web all workspaces are virtual. CC
is right, and I agree it's a bit confusing. The npm extension has a main entry point where it contributes code completions and hovers for the in It uses online services for that, so it also works with virtual workspaces. That said, it should not say but instead just disable the functionality that doesn't work when in a virtual workspace.
What do we want to change? that is observed in the web that the npm extension does not declare ?
I would propose the following changes: extension does not declare , can we make the npm extension activate less eagerly i.e. not on ? Today the npm extension activates whenever we open a VS Code extension repo for e.g., which seems unnecessary. Maybe we could instead activate when a file is opened? (I don't believe we have an activation event for this but perhaps we could introduce one?)
is currently needed to set the context variable that is used to enable/disable the npm explorer.
I don't think we have a work around for the context value, so we need to keep the activation as is.
Change:
'union', 'unsigned', 'using', <del> 'value', </del> 'virtual', 'void', 'volatile',

Discussion:
Problem A fair number of extensions are shipping , , and files. Except for a few exceptional circumstances, these files are not needed in the extension bundle itself. A few also include test code Proposal For the for , add:For existing extensions, can we add a linter alert or vsce alert for these cases?Use bot to go through offending extensions and open issues?
Probably should also add . A good number of the top 500 extensions also include that
Manually opened a few PRs against larger offenders of including files Opened to improve the starter
Created
Can you please take a look at too
Change:
* Change the scroll position of the editor's viewport. */ setScrollPosition(position: editorCommon.INewScrollPosition, scrollType?: editorCommon.ScrollType): void; <ins> /** * Check if the editor is currently scrolling towards a different scroll position. */ hasPendingScrollAnimation(): boolean; </ins> /** * Get an action that is a contribution to this editor.

Discussion:
Type: <bBug</bI found this problem in Vim extension when using half page scroll with centered view and smoothScrolling, and reproduce this bug in test clean extension. Without smoothScrolling it works fine. When executing command two times with ~150ms delay second action dont trigger (view stay in position by first ). U can see it on this video, when view in some cases not returned to 31 line from 39. https://user- Reproduce: reproducing i set interval with two timeouts to create delay between two executions and set smoothScrolling. ! VS Code version: Code 1.76.2 (, 2023-03-14T17:55:54.936Z) OS version: WindowsNT x64 10.0.

Modes: Unsupported Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (35)</summaryExtensionVersion ------ better-comments3.0.2 astro-vscode0.28.2 vscode-tailwindcss0.9.11 path-intellisense2.8.4 vscode-css-modules0.4.2 vscode-database-client26.3.4 vscode-eslint2.4.0 es7-react-js-snippets4.4.3 vsc-material-theme-icons2.7.4 prettier-vscode9.10.4 auto-close-tag0.5.14 auto-rename-tag0.1.10 code-runner0.12.0 geril-vim1.25.2 go0.38.0 vscode-graphql0.8.7 vscode-graphql-syntax1.1.0 code-background2.5.4 vscode-docker1.24.0 remote-wsl0.76.1 remote-explorer0.4.0 remote-server1.0.0 material-icon-theme4.25.0 prisma4.12.0 LiveServer5.7.9 rust-analyzer0.3.1463 vscode-styled-components1.7.8 svelte-vscode107.3.0 errorlens3.8.0 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-icons12.2.0 JavaScriptSnippets1.8.0 material-theme3.15.8 vscode-proto30.5.5 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.77.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
After update to 1.77.1 bug still exists
Thank you for the repro! The root cause is this particular call - introduced via cc That code runs even when the inlayHintsController doesn't do anything and it ends up interrupting the current editor scroll animation.