jiebi/CodeConvo huggingface dataset:
Code change:
} private handleExtensionData(extensions: IssueReporterExtensionData[]) { <del> const { nonThemes, themes } = collections.groupBy(extensions, ext => { </del> <ins> const installedExtensions = extensions.filter(x => !x.isBuiltin); const { nonThemes, themes } = collections.groupBy(installedExtensions, ext => { </ins> return ext.isTheme ? 'themes' : 'nonThemes'; }); const numberOfThemeExtesions = themes && themes.length; <del> this.issueReporterModel.update({ numberOfThemeExtesions, enabledNonThemeExtesions: nonThemes, allExtensions: extensions }); </del> <ins> this.issueReporterModel.update({ numberOfThemeExtesions, enabledNonThemeExtesions: nonThemes, allExtensions: installedExtensions }); </ins> this.updateExtensionTable(nonThemes, numberOfThemeExtesions); <del> if (this.environmentService.disableExtensions || extensions.length === 0) { </del> <ins> if (this.environmentService.disableExtensions || installedExtensions.length === 0) { </ins> (<HTMLButtonElement>this.getElementById('disableExtensions')).disabled = true; } <del> this.updateExtensionSelector(extensions); </del> <ins> this.updateExtensionSelector(installedExtensions); </ins> } private handleSettingsSearchData(data: ISettingsSearchIssueReporterData): void {

Related discussion:
text: Feature Request The command takes an extension argument so that extensions can open an issue reporter for that extension. I'd like to use this for the built-in JS/TS extension as well but cannot at the moment: It'd be nice if for VS Code builtin extensions, we automatically changed the field to
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to upvote 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!
Code change:
action: (!this.isQuickNavigate() && currentWindowId !== win.id) ? this.closeWindowAction : void 0 } as IFilePickOpenEntry)); <ins> const autoFocusIndex = (picks.indexOf(picks.filter(pick => pick.payload === currentWindowId)[0]) + 1) % picks.length; </ins> this.quickOpenService.pick(picks, { contextKey: 'inWindowsPicker', <del> autoFocus: { autoFocusFirstEntry: true }, </del> <ins> autoFocus: { autoFocusIndex }, </ins> placeHolder, quickNavigateConfiguration: this.isQuickNavigate() ? { keybindings: this.keybindingService.lookupKeybindings(this.id) } : void 0 });

Related discussion:
text: I'm using the on a keybinding to quickly switch between different components in a project. A slightly frustrating behavior is that the window list appears in the same order in both windows. This means that when you do , the first window in the list is always selected. So, if you have 2 windows open and you're switching back and forth between them, you have to remember two key combinations, one for each window you're in: Switching from Window 1 to Window 2: Switching from Window 2 to Window 1: only I propose defaulting the selection to be the first entry that is not the current window. That way, it is a "quick switch" indeed. :) Thoughts? I will implement this when I have time if there is no objection.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.612 --<!-- potentialduplicatescomment --
Don't believe this is a duplicate - the other issues think this unexpected behavior is a bug, while this issue proposes a way to make the behavior closer to what the user expects.
Another way this could work is to by default, select the window after the current window in the window switcher. So you can quickly flip through 3 or more windows.
Code change:
'For instructions, see http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx.</value>', '                      http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx         ' ); <ins> assertLink( 'x = "https://en.wikipedia.org/wiki/Zürich";', '     https://en.wikipedia.org/wiki/Zürich  ' ); assertLink( '請參閱 http://go.microsoft.com/fwlink/?LinkId=761051。', '    http://go.microsoft.com/fwlink/?LinkId=761051 ' ); assertLink( '（請參閱 http://go.microsoft.com/fwlink/?LinkId=761051）', '     http://go.microsoft.com/fwlink/?LinkId=761051 ' ); </ins> // foo bar (see http://www.w3schools.com/tags/att_iframe_sandbox.asp) });

Related discussion:
text: VSCode Version: 1.0 OS Version: OS X 10.11.4 I just upgraded my VSCode to 1.0 release. Since it supports Traditional Chinese now, my default language was set to so that some of comments in the newly config file is in Chinese. As you can see in the following screenshot, a Chinese character "", which is equivalent to the period "." in English, was matched as part of valid URL, and it caused VSCode direct to a incorrect URL. ! I have a working fix for this issue, the naive solution is to check if in is greater than 128, which means a non-ASCII character. Why to match only ASCII character? Because when you copy a URL from most of web browsers to clipboard, it will be automatically converted into ASCII-only string. Also, I came up with another idea to modify the to let it cache all the result of ASCII characters (0~127). In this way, we only need to modify the default case of the switch clause in the state machine. Which solution is more preferable? Please give me some advice then I can submit the patch ASAP.
Code change:
"badge.background": "#705697AA", "progressBar.background": "#705697" } <del> } </del>  No newline at end of file <ins> } </ins>

Related discussion:
text: "Add" text in these screenshots. JSX ! HTML !
That's just how it it. All depends on what scopes the differents grammars (html: no scope), jsx: ) use and the decisions of the themes on what to colors. The workround is to use a theme that doesn't color , e.g. the default light theme.
fixed by , thanks
Code change:
*--------------------------------------------------------------------------------------------*/ import { KeyCode, KeyMod } from 'vs/base/common/keyCodes'; <del> import { Disposable, DisposableStore } from 'vs/base/common/lifecycle'; </del> <ins> import { Disposable, DisposableStore, IDisposable, MutableDisposable } from 'vs/base/common/lifecycle'; </ins> import { localize } from 'vs/nls'; import { CONTEXT_ACCESSIBILITY_MODE_ENABLED } from 'vs/platform/accessibility/common/accessibility'; import { Action2, registerAction2 } from 'vs/platform/actions/common/actions';

Related discussion:
text: Type: <bFeature Request</bCC Please consider auto-activiating accessible view in terminal when user hit enter key. In most cases, screen reader users want to open accessible view after executing command in terminal. Thus, pressing Enter key can do: the current command to terminal. Accessible View immediately. Rather than having this as the default mode, we could consider adding this as a custom user setting. VS Code version: Code - Insiders 1.85.0-insider (, 2023-11-02T09:02:24.464Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
This makes sense. let us know if you have any thoughts.
I imagine this mode can boost user productivity because VSCode now sends user typing in Accessible View directly to the active terminal. If this mode is , users will experience more seamless round trip between terminal input and accessible view without having to press Alt+F2 and ESC.
To verify, enable . Run a command in the terminal. The accessible view should open.
Code change:
const baseConfig: IOpenConfiguration = { context, cli: args, <del> userEnv, </del> <ins> /** * When opening a new window from a second instance that sent args and env * over to this instance, we want to preserve the environment only if that second * instance was spawned from the CLI or used the `--preserve-env` flag (example: * when using `open -n "VSCode.app" --args --preserve-env WORKSPACE_FOLDER`). * * This is done to ensure that the second window gets treated exactly the same * as the first window, for example, it gets the same resolved user shell environment. * * https://github.com/microsoft/vscode/issues/194736 */ userEnv: (args['preserve-env'] || context === OpenContext.CLI) ? userEnv : undefined, </ins> waitMarkerFileURI, remoteAuthority, forceProfile: args.profile,

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.82.3 OS Version: Ventura 13.6 This one was tricky to investigate and is impacting the and & scenario. In that scenario, VS Code is started from one application using the macOS command. This reproduces without requiring Unity and with no extension installed. This seems to be a macOS only issue. When opening either from the macOS Finder or through , the VS Code application will expand the PATH of its subprocess so that extensions that depend on something in the path of the terminal will find it. So in my case, if I start VS Code from the Finder, the processes will look like this: This is expected and good. Extensions can find in the PATH. The issue is that now, if I want to open another workspace in the same instance (but launched from another application), the PATH doesn't get expanded in the second workspace and I get: So in my second workspace, will not be found in the PATH.
Code change:
const baseConfig: IOpenConfiguration = { context, cli: args, <del> userEnv, </del> <ins> /** * When opening a new window from a second instance that sent args and env * over to this instance, we want to preserve the environment only if that second * instance was spawned from the CLI or used the `--preserve-env` flag (example: * when using `open -n "VSCode.app" --args --preserve-env WORKSPACE_FOLDER`). * * This is done to ensure that the second window gets treated exactly the same * as the first window, for example, it gets the same resolved user shell environment. * * https://github.com/microsoft/vscode/issues/194736 */ userEnv: (args['preserve-env'] || context === OpenContext.CLI) ? userEnv : undefined, </ins> waitMarkerFileURI, remoteAuthority, forceProfile: args.profile,

Related discussion:
text: For this to happen, VS Code must be started from an application launched from the Finder (and not from the Terminal, otherwise it will inherit the PATH of the Terminal) Steps to Reproduce: Xcode, create a new SwiftUI project (I mean, it doesn't have to be a SwiftUI project, you can re-create the issue with anything that is able to output a macOS .app but for this particular repro I used SwiftUI) the Sandbox for the project: <img width="562" alt="Screenshot 2023-10-03 at 10 33 02 AM" src=""the look like this: the variables and to point to 2 different workspaces. the project, I personally use in command line. all VS Code instances. the .app from the Finder, it will be in if you built from the command line by default. the button As you can see from the code, the .app will: set the PATH with a marker open a new VS Code workspace on workspace1 wait a bit open a new VS Code workspace on workspace2 activity monitor, find the child process ID: <img width="1045" alt="Screenshot 2023-10-03 at 10 40 50 AM" src=""the terminal, look at their path: (Your pid may vary) that the second child process doesn't have its PATH expanded, and only inherited the PATH from the .app:
I think you're best equip to handle this issue? but feel free to reassign to whoever.
I can't repro this. To know more, please do the following: Quit VS Code From a Terminal, run , this should open VS Code In that window, run and set it to . Then, from a Terminal, run , this should open the second window On the second window, reveal the Output panel and the Window logs. Search for , what do you find?
the entire point of long repro is to not start VS Code from the terminal, but from an app launched from macOS. As I said in the bug:
Using is the same as launching from Finder. Let me know the result.
Code change:
const baseConfig: IOpenConfiguration = { context, cli: args, <del> userEnv, </del> <ins> /** * When opening a new window from a second instance that sent args and env * over to this instance, we want to preserve the environment only if that second * instance was spawned from the CLI or used the `--preserve-env` flag (example: * when using `open -n "VSCode.app" --args --preserve-env WORKSPACE_FOLDER`). * * This is done to ensure that the second window gets treated exactly the same * as the first window, for example, it gets the same resolved user shell environment. * * https://github.com/microsoft/vscode/issues/194736 */ userEnv: (args['preserve-env'] || context === OpenContext.CLI) ? userEnv : undefined, </ins> waitMarkerFileURI, remoteAuthority, forceProfile: args.profile,

Related discussion:
text: I'm afraid it's not exactly the same as it exhibits a different behavior as it appears the second instance of the process will simply inherit the PATH of the process that started it, instead of expanding the PATH to be like a terminal Using twice will work as expected from the Terminal as the second instance of the process will inherit the PATH of the Terminal. Using the repro steps to create an app that will call on Visual Studio Code twice won't work as expected. If I close all VSC instances, and do twice on two different workspaces, I get: Things are visibility different as the main Code process seems to inherits the PATH from the Terminal. Whereas if I launch Code manually from the Finder, I get: So there is a difference.
Thanks for testing! Very interesting, I was unaware of differences here. Last I saw this (when I did the macOS integration years ago), did not propagate environments. It seems like it does now. Can you try just once more with: , replacing with the path to the workspace? Thanks, I really appreciate it!
Version: 1.84.0-insider Commit: With from the Terminal I get the same behavior as :
Hi we're seeing a growing number of customer reports on this. I think I've provided all the info that was needed including a way to create a self-contained repro. How could we get this looked at? Thanks!
Same here guys. Just installed unity + vscode and have this message about missing net sdk. I came from here.
I came here from microsoft/vscode-dotnettools as well – and I'm glad I did! I've been banging my head against the " isn't on the PATH" issue (and related!) for quite a long while and with insight from the fantastic writeup for this issue was able to get it to work again. For me, the break comes down to how I open my Unity project in VS Code. I generally open my Unity Projects is with the following: the project in Unity. "Open C# Project" from the Assets menu. <img width="253" alt="image" src=""If the project isn't already open, Visual Studio Code will open up a new window and load the project. When this happens, I get all the "I can't find !" issues. a new VS Code window (keyboard shortcut/menu/palette/whatever).
Code change:
const baseConfig: IOpenConfiguration = { context, cli: args, <del> userEnv, </del> <ins> /** * When opening a new window from a second instance that sent args and env * over to this instance, we want to preserve the environment only if that second * instance was spawned from the CLI or used the `--preserve-env` flag (example: * when using `open -n "VSCode.app" --args --preserve-env WORKSPACE_FOLDER`). * * This is done to ensure that the second window gets treated exactly the same * as the first window, for example, it gets the same resolved user shell environment. * * https://github.com/microsoft/vscode/issues/194736 */ userEnv: (args['preserve-env'] || context === OpenContext.CLI) ? userEnv : undefined, </ins> waitMarkerFileURI, remoteAuthority, forceProfile: args.profile,

Related discussion:
text: the project from within VS Code. In my case, I do this via the "Open Recent..." menu as what I'm looking for is usually listed there. Regardless, if I open the project in VS Code in this manner, everything works as expected.
sorry for the silence here. Let's try to figure this one out. First of all, I can't get your Swift sample to work. It launches VS Code but fails to open each workspace properly, even after triple checking that I've changed both workspace paths to something that exists. I really couldn't figure out why... In any case, can I ask you for one more piece of info? from Finder (main process regular PATH, Code Helper with sourced PATH) a Terminal, call the command with the path to the second workspace. What's the of that second Code Helper process that comes up? Resolved?
Hey thanks for bumping this, happy new year, looking forward to having a resolution for this. That happened to me before I turned the sandbox off. See step 2 of the repro? We could also try the real world scenario with Unity, but it's going to be a slightly longer setup, I'd encourage you to reach out to my email at work to help get you setup. In that case: The main Visual Studio App inherits the PATH of the Finder (so just /usr/bin:/bin) The first process gets a PATH expended. The second process inherits the PATH of the Terminal, verified by doing: Just before calling in the Terminal.
Sorry about that. It runs correctly now! And I can repro! Funny: it seems to only affect the variable. If, say, one adds to , that gets properly propagated to both extension hosts (). Interesting, digging more...
Nice! Good luck :)
Got it!
<!-- 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
Code change:
async setLocale(languagePackItem: ILanguagePackItem, _skipDialog = false): Promise<void> { const locale = languagePackItem.id; <del> if (locale === Language.value() || (!locale && Language.value() === navigator.language)) { </del> <ins> if (locale === Language.value() || (!locale && Language.value() === navigator.language.toLowerCase())) { </ins> return; } if (locale) {

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: : 1.81.0-insider : : 2023-07-12T11:13:11.418Z : Mozilla/5.0 (Macintosh; Intel Mac OS X ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36 OS Version: Mac os 12.2.1 (21D62) Steps to Reproduce: Configuration Display Language to . devtools after page auto refresh !
eg. does not exist, but exists.
thanks for working on this. The true fix for this issue actually needs to be in 's source code. I've made that fix and this should work for you now. Let me know if you still see any trouble.
Code change:
const groupActiveEditorAvailableEditorIds = this.editorPartsView.bind(ActiveEditorAvailableEditorIdsContext, this); const groupActiveEditorCanSplitInGroupContext = this.editorPartsView.bind(ActiveEditorCanSplitInGroupContext, this); <del> const sideBySideEditorContext = this.editorPartsView.bind(SideBySideEditorActiveContext, this); </del> <ins> const groupActiveEditorIsSideBySideEditorContext = this.editorPartsView.bind(SideBySideEditorActiveContext, this); </ins> const activeEditorListener = this._register(new MutableDisposable());

Related discussion:
text: Reproduced on OSS, Mac Steps to Reproduce: Code OSS a file cmd+w Closes the window Bisect points to this commit -
I can reproduce and this is likely context keys not being set properly because conditionally closes the window if no active editor. !
There are context keys that are now loose, for example
Follow up work
Code change:
[UninstallDelete] Type: filesandordirs; Name: "{app}_" <del> Type: filesandordirs; Name: "{app}old" </del> [Tasks] Name: "desktopicon"; Description: "{cm:CreateDesktopIcon}"; GroupDescription: "{cm:AdditionalIcons}"; Flags: unchecked

Related discussion:
text: Bug ! vscode-inno- VS Code version: Code - Insiders 1.21.0-insider (, 2018-02-09T06:14:31.856Z) OS version: Windows_NT ia32 6.1.7601 <details<summarySystem Info</summary </detailsExtensions: none Reproduces without extensions
Thanks! Very interesting. Can you somehow check which process has an open handle on ? I usually use for this.
I have the same problem. Using Process Hacker, I got this result: !. Even after closing MEGAsync, I still get this problem. ! Here's the content of the log file: The last line means .
!
When VS Code isn't running, I can move/rename this file without problems.
BTW, my OS is Windows 7 Pro x64, not "Windows_NT ia32 6.1.7601" as reported by VS Code. What's your OS?
I'm on Windows 7 Pro x86 (6.1.7601 Service Pack 1 version 7601). I haven't tested on other architectures yet.
Love it that you guys are already collecting stuff for me. I'm getting a Windows 7 image and trying it out. Can you also give me the list of extensions you currently have installed?
It works for me: Windows 10 Home(Build .rs2_release.-1834) I'm paying attention to the next updates, perhaps I can give you the needle of information.
has no extensions it seems (according to his first post). For my part, I have plenty ones: <details<summaryExtensions</summary- Bracket Pair Colorizer C/C++ C# Clang-Format CMake Code Runner cpplint Debugger for Chrome Doxygen Doxygen Documentation Generator Git History Git Project Manager gitignore GitLens - Git supercharged HTML CSS Support HTML Snippets IntelliSense for CSS class names JavaScript (ES6) code snippets jshint LaTeX Compile LaTeX Preview LaTeX Workshop latex-formatter Markdown All In One Markdown PDF Markdown Preview Enhanced markdownlint mssql npm One Dark Pro PHP Debug PHP IntelliSense PowerShell Python Unicode Latex VS Live Share vscode-icons vscode-pdf </details
I could easily reproduce in Windows 7!
Perfect :)
I am having an issue updating Visual Studio Code - Insider's Build,