jiebi/CodeConvo huggingface dataset:
Change:
fontWeight?: string; fontSize?: string; fontFamily?: string; <ins> unicodeBidi?: string; </ins> textDecoration?: string; color?: string | ThemeColor; backgroundColor?: string | ThemeColor;

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 (though an extension that introduces inlay hints is required) <!-- 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: Windows_NT x64 10.0. Steps to Reproduce: a new rust project with . a font for VSCode that has a ligature for , install and set the config. the cargo project in VSCode and paste the following snippet into the file: Watch how there is an inlay hint inserted in front of both which merges with the leading . Actual result: ! Note that in my theme, inlay hints are dimmed ! but due to the ligature forming, the inlay hint looks like its part of the default code. Expected result ( apparently this can depend on the theme): ! (Different themes are due to running the rust-analyzer fix in the debugger without a custom theme) This also occurs for when two different inlay hints follow each other, as seen in
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.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Confirmed to also occur on 1.74.2
can a decoration force ligature boundaries?
Turns out even inserting a zero-width non joiner doesn't prevent ligatures from forming (for some reason using a builtin theme prevents the ligature from forming, unsure why)
Btw the assigned label is incorrect, this is not a problem with but with
! An obvious example. expected: !

I think this should be on the May milestone?
could you verify this one as you have a rust setup?
Can confirm it is fixed with the latest release! Thanks
Thanks
Change:
assert.strictEqual(path.extname('far.boo/boo'), ''); }); <del> (isWeb && isWindows ? test.skip : test)('resolve', () => { // TODO@sbatten fails on windows & browser only </del> <ins> test('resolve', () => { </ins> const failures = [] as string[]; const slashRE = ///g; const backslashRE = //g;

Discussion:
We will ship Electron with to stable soon so we should also look into bringing our copy of library to the same version. Checking for the diff, it seems to be a few commits after and up until //cc
Hm, the first change is already pretty bad for us: Because it seems to depend on a new thing which is maybe defined globally and probably optimised / cached / snapshotted. Maybe we should rather look out for actual bug fixes and focus on those... Changes: I think only the 2 fix commits stand out from the others
I assume you skipped over right?
Reopening given unit test failures, I had to revert the change for now.
yes I skipped the primordials. I didn't dig into why they do this, but it seemed easy enough to just call the string functions instead. As for the test failures, new PR
Primordials are only meant for Nodejs internal code usage, external users should just replace them with corresponding JavaScript builtins. You can read more about why Nodejs does it
Change:
import { IUriIdentityService } from 'vs/workbench/services/uriIdentity/common/uriIdentity'; import { IContextKey, IContextKeyService } from 'vs/platform/contextkey/common/contextkey'; import { Expression } from 'vs/workbench/contrib/debug/common/debugModel'; <ins> import { themeColorFromId } from 'vs/platform/theme/common/themeService'; import { registerColor } from 'vs/platform/theme/common/colorRegistry'; </ins> const LAUNCH_JSON_REGEX = /.vscode/launch.json$/; const INLINE_VALUE_DECORATION_KEY = 'inlinevaluedecoration';

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. --The inlines values colors are currently hardcoded: These should be abstracted to a themable color, either its own dedicated color or one of the , I would recommend hint or info.
I agree with this. Let's put a help wanted, sounds like a good thing to be tackled by the community. If nobody is interested I can also look into this in the future
Thanks to this is now fixed can you maybe try this out with VS Code insiders from tomorrow and let us know how it works for you. The new color names are:
Thank you, will test. Cc EDIT: Doesn't appear to have landed in yesterdays insiders, will check tomorrow.
Change:
} async function main(arch = process.arch): Promise<void> { <del> const version = product.electronRepository ? '22.4.4' : util.getElectronVersion(); </del> <ins> const version = product.electronRepository ? '22.4.5' : util.getElectronVersion(); </ins> const electronPath = path.join(root, '.build', 'electron'); const versionFile = path.join(electronPath, 'version'); const isUpToDate = fs.existsSync(versionFile) && fs.readFileSync(versionFile, 'utf8') === `${version}`;

Discussion:
The Angular language service extension spawns a child process using and listens for the and events. The current version works as expected. Without any changes to the project, simply updating to results in the forked child process acting differently (never erroring and never closing). I'm using Mac 13.3.1 but we also had a report that the forked process isn't working in WindowsNT x64 10.0. either. There was a similar issue (though not entirely the same) a while back: Apologies for the rather involved reproduction... Here's how I'm able to reproduce and compare the behavior between the versions: our the repository with vscode insider version 1.78.0-insiders out the branch (we're actually removing this in the next version so it doesn't exist on ) dependencies with debugging, put a debugger statement before and one in the . The project is built with bazel so breakpoints would have to be put in the compiled JS files. the build script with the extension development host (Dev Client + Server run configuration) In the extension host, open the and then open the template file -- debugger should stop on the fork and if you continue, you will see that the debugger stops in the stderr data listener but never in the or . The output of the stderr also indicates that it is listening for a debugger and that it gets attached. The fork used which should have prevented this. The process also never produces any results or completes. You can have the fork retry by running the Angular: Restart Angular Language server command in the extension host. I've also verified that the spawn args are the same between versions and both include "--ms-enable-electron-run-as-node".
Issue was caused by the allocator changes to processes which now schedule delayed tasks to purge memory cache ;l=1183 and that revealed a bug in the causing the process to hang.
<!-- 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!
Change:
// make sure that the webview is not visible otherwise users will see pre-rendered markdown cells in wrong position as the list view doesn't have a correct `top` offset yet this._webview!.element.style.visibility = 'hidden'; // warm up can take around 200ms to load markdown libraries, etc. <del> await this._warmupViewport(viewModel, viewState); </del> <ins> await this._warmupViewportMarkdownCells(viewModel, viewState); </ins> this.logService.debug('NotebookEditorWidget', 'warmup - viewport warmed up'); // todo@rebornix @mjbvz, is this too complicated?

Discussion:
Type: <bBug</ba jupyter notebook, create a python cell the cell the notebook two earch results the notebook bug One of the search results goes away <img width="1179" alt="Screenshot 2023-04-25 at 11 09 04 AM" src="https://user-"Making any changes to the search term makes both search results show again VS Code version: Code - Insiders 1.78.0-insider (Universal) (, 2023-04-25T05:41:22.331Z) OS version: Darwin x64 22.4.0 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<!-- generated by issue reporter --
Change:
*--------------------------------------------------------------------------------------------*/ import { Disposable, MutableDisposable } from 'vs/base/common/lifecycle'; <del> import { Event } from 'vs/base/common/event'; import Severity from 'vs/base/common/severity'; </del> import { localize } from 'vs/nls'; import { IAccessibilityService } from 'vs/platform/accessibility/common/accessibility'; <del> import { CommandsRegistry } from 'vs/platform/commands/common/commands'; import { ConfigurationTarget, IConfigurationService } from 'vs/platform/configuration/common/configuration'; import { INotificationHandle, INotificationService, NotificationPriority } from 'vs/platform/notification/common/notification'; </del> <ins> import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; </ins> import { IWorkbenchContribution } from 'vs/workbench/common/contributions'; import { IStatusbarEntryAccessor, IStatusbarService, StatusbarAlignment } from 'vs/workbench/services/statusbar/browser/statusbar'; export class AccessibilityStatus extends Disposable implements IWorkbenchContribution { <del> private screenReaderNotification: INotificationHandle | null = null; private promptedScreenReader: boolean = false; </del> private readonly screenReaderModeElement = this._register(new MutableDisposable<IStatusbarEntryAccessor>()); constructor( <del> @IConfigurationService private readonly configurationService: IConfigurationService, @INotificationService private readonly notificationService: INotificationService, </del> <ins> @IConfigurationService configurationService: IConfigurationService, </ins> @IAccessibilityService private readonly _accessibilityService: IAccessibilityService, @IStatusbarService private readonly statusbarService: IStatusbarService ) {

Discussion:
We should not prompt IMO anymore since we detect the screen reader.
let's discuss this on Monday
I like the idea, but I suggest that we leave the prompt for at least one more milestone. After that, we can compare the number of accessibility users we have after changes and see how precise the detection is. We might also see that the detection is more precise on some platforms, in which case we can leave the prompt only for some platforms. Does that make sense? What do you think? fyi who introduced the prompt initially
Safe to remove now?
I suggest to leave it on for at least one more milestone since our accessibility detection got off. I will assign it to March for now. Hope that is ok.
Thanks for fixing this. I just assigned to October and verification-needed. I think the verify steps are the following: On Windows turn on NVDA VS Code insiders (have no settings set). an editor, type some text sure NVDA reads this text as you navigate through it character by character Same on macOS with VoiceOver.
I haven't heard user complaints, so let's just keep this
Change:
|| /^command:(///)?_workbench.downloadResource/i.test(href) ) { // drop the link <del> a.replaceWith(a.textContent ?? ''); </del> <ins> a.replaceWith(...a.childNodes); </ins> } else { let resolvedHref = _href(href, false); if (markdown.baseUri) {

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.68.0 OS Version: Linux x64 5.18.3-zen1-1-zen Steps to Reproduce: code display nothing.
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
Actually this is already enabled, you just need to set as well as . The bug is that theme icons gets stripped from an without an href
<!-- 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!
/verified
Change:
const electronOpts = _.extend({}, config, { platform: process.platform, arch: arch === 'armhf' ? 'arm' : arch, <del> ffmpegChromium: true, </del> <ins> ffmpegChromium: false, </ins> keepDefaultApp: true });

Discussion:
The Angular language service extension spawns a child process using and listens for the and events. The current version works as expected. Without any changes to the project, simply updating to results in the forked child process acting differently (never erroring and never closing). I'm using Mac 13.3.1 but we also had a report that the forked process isn't working in WindowsNT x64 10.0. either. There was a similar issue (though not entirely the same) a while back: Apologies for the rather involved reproduction... Here's how I'm able to reproduce and compare the behavior between the versions: our the repository with vscode insider version 1.78.0-insiders out the branch (we're actually removing this in the next version so it doesn't exist on ) dependencies with debugging, put a debugger statement before and one in the . The project is built with bazel so breakpoints would have to be put in the compiled JS files. the build script with the extension development host (Dev Client + Server run configuration) In the extension host, open the and then open the template file -- debugger should stop on the fork and if you continue, you will see that the debugger stops in the stderr data listener but never in the or . The output of the stderr also indicates that it is listening for a debugger and that it gets attached. The fork used which should have prevented this. The process also never produces any results or completes. You can have the fork retry by running the Angular: Restart Angular Language server command in the extension host. I've also verified that the spawn args are the same between versions and both include "--ms-enable-electron-run-as-node".
Issue was caused by the allocator changes to processes which now schedule delayed tasks to purge memory cache ;l=1183 and that revealed a bug in the causing the process to hang.
<!-- 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!
Change:
this.disposables.push(languages.registerCodeActionsProvider(selector, new (await import('./features/refactorProvider')).default(client, this.formattingOptionsManager, commandManager))); this.registerVersionDependentProviders(); <del> const referenceCodeLensProvider = new (await import('./features/referencesCodeLensProvider')).default(client, this.description.id); </del> <ins> const cachedResponse = new CachedNavTreeResponse(); const referenceCodeLensProvider = new (await import('./features/referencesCodeLensProvider')).default(client, this.description.id, cachedResponse); </ins> referenceCodeLensProvider.updateConfiguration(); this.toUpdateOnConfigurationChanged.push(referenceCodeLensProvider); this.disposables.push(languages.registerCodeLensProvider(selector, referenceCodeLensProvider)); <del> const implementationCodeLensProvider = new (await import('./features/implementationsCodeLensProvider')).default(client, this.description.id); </del> <ins> const implementationCodeLensProvider = new (await import('./features/implementationsCodeLensProvider')).default(client, this.description.id, cachedResponse); </ins> implementationCodeLensProvider.updateConfiguration(); this.toUpdateOnConfigurationChanged.push(implementationCodeLensProvider); this.disposables.push(languages.registerCodeLensProvider(selector, implementationCodeLensProvider));

Discussion:
<!-- Do you have a question? Please ask it on --- VSCode Version: Version 1.12.1 (1.12.1) OS Version: Windows 64 bits This issue is not a bug but just a suggestion/idea to improve CodeLens performance for TypeScript when and are activated. In this case tsserver command which can take times and response can be big is called twice: one call of navtree for providing references CodeLens. one call of navtree for providing implementation CodeLens. I tell me if CodeLens provider could manage a shared context to store some data that other code lens provider could use it. For instance in this case, we could have just one call of navtree: one call of navtree for providing references CodeLens and store the result in a shared context. the implementation CodeLens provider search navtree from the shared context.
Change:
}); test('findFiles', () => { <del> return vscode.workspace.findFiles('*.png').then((res) => { </del> <ins> return vscode.workspace.findFiles('**/*.png').then((res) => { assert.equal(res.length, 2); assert.equal(basename(vscode.workspace.asRelativePath(res[0])), 'image.png'); }); }); test('findFiles, exclude', () => { return vscode.workspace.findFiles('**/*.png', '**/sub/**').then((res) => { </ins> assert.equal(res.length, 1); assert.equal(basename(vscode.workspace.asRelativePath(res[0])), 'image.png'); });

Discussion:
Use this code in an extension, run the command In 1.31, it returns no results because takes a single glob pattern In 1.32, it returns results because the include and exclude patterns for are split on the comma
This is a candidate because it would be an API change. If we want to support multiple glob patterns we should use an array like we discussed in Parsing a comma-delimited string in this API feels wrong.

1) use yo code to create an extension 2) Replace the with the code below 4) Press F5 to run the workspace 5) Open a project for a node module that has a nodemodules folder with many modules. 6) Execute the ´Hello World' command --the call workspace.findFiles returns file matches from the folder, but the nodemodules folder is excluded. Running the same extension in stable properly excludes matches in the folder. Tagging as a candiate for February since the change of behavour impacts NPM script running and now proposes scripts from the node_modules. The code for
Would be fixed by .
Change:
} const workbenchContributionsRegistry = Registry.as<IWorkbenchContributionsRegistry>(WorkbenchExtensions.Workbench); <del> // PreferencesActionsContribution is heavy because it runs through various details to determine which actions to render. // We don't need it to start so early. workbenchContributionsRegistry.registerWorkbenchContribution(PreferencesActionsContribution, 'PreferencesActionsContribution', LifecyclePhase.Restored); </del> <ins> workbenchContributionsRegistry.registerWorkbenchContribution(PreferencesActionsContribution, 'PreferencesActionsContribution', LifecyclePhase.Starting); </ins> workbenchContributionsRegistry.registerWorkbenchContribution(PreferencesContribution, 'PreferencesContribution', LifecyclePhase.Starting); registerEditorContribution(SettingsEditorContribution.ID, SettingsEditorContribution);

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/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: Version: 1.72.0-insider (Universal) Commit: OS Version: macOS 12.5.121G83 Steps to Reproduce: latest VSCode Insiders cmd + , <img width="299" alt=" 2022-09-02 18 41 29" src="https://user-"<img width="268" alt=" 2022-09-02 18 41 41" src="https://user-"
Keybinding is missing on today's Insiders: ! could have caused this?
Added macos label because it seems to work fine on Windows.
my screenshot was from a Windows instance of Insiders.
It might be caused by that commit, but I'm still unable to repro the issue on Windows 10 or macOS Big Sur.
When I downloaded the latest Insiders to the Download folder and ran it, this did not reproduce. It may happen when updating a global install, but I have not been able to verify this yet.
Change:
resolved "https://registry.yarnpkg.com/xterm-addon-webgl/-/xterm-addon-webgl-0.12.0-beta.36.tgz#460f80829a78c979a448d5b764699af3f0366ff1" integrity sha512-sgX7OHSGZQZE5b4xtPqd/5NEcll0Z+00tnTVxKZlXf5XEENcG0tnBF4I4f+k9K3cmjE1UIUVG2yYPrqWlYCdpA== <del> xterm-headless@4.19.0-beta.47: version "4.19.0-beta.47" resolved "https://registry.yarnpkg.com/xterm-headless/-/xterm-headless-4.19.0-beta.47.tgz#9d5af8145c42b9a6241a040bb244b877c149761b" integrity sha512-chVTURPMNDEerQIsN4lIRotpXCfJsTHioZGQxDBNdktZO1gMXGvNxDjzsbsJg5ikLN5llz/HLDfXZrjCeb3elg== xterm@4.19.0-beta.47: version "4.19.0-beta.47" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.47.tgz#f5931201346a485e3bcb29d24e83583727e55707" integrity sha512-c8EcCSWCHnFYNdRMTnJIpYTV9J2Ze7kdB1GhTcPO2ipMEsqaP/u6Ca8rgBWwV9HeEVfe4rGRqWW2qcSy4U9hMQ== </del> <ins> xterm-headless@4.19.0-beta.49: version "4.19.0-beta.49" resolved "https://registry.yarnpkg.com/xterm-headless/-/xterm-headless-4.19.0-beta.49.tgz#8e4178620be9a9dee25a586ef992a6fc621a829a" integrity sha512-uRnHpR2pv1MJPbE3sa7XbP6x0uHubAWVMbiD26e3a5ICtWJQVVpLojkA0t4qU7CoMX85pRL1rIclg9CKY0B0xA== xterm@4.19.0-beta.49: version "4.19.0-beta.49" resolved "https://registry.yarnpkg.com/xterm/-/xterm-4.19.0-beta.49.tgz#96d0d748c97a2f0cfa4c6112bc4de8b0d5d559fe" integrity sha512-qPhOeGtnB357mZOvfDckVlPDR7EDkSASQrB3aujhjgJlOiBBqcNRJcuSvF7v1DOho7xdEI9UQxiSiT5diHhMlg== </ins> yallist@^4.0.0: version "4.0.0"

Discussion:
Theme pictured is Sapphire. ! Possibly related to Code pointer
Blending colors in vscode yields rgba format, so we should add that support to !
issue
Repro for this is to set the following settings and try find in terminal:

Started seeing this yesterday: !
This seems to be related to my theme, probably same root cause as
Repro for this is to set the following settings and try find in terminal: