jiebi/CodeConvo huggingface dataset:
Code change:
@IExtHostExtensionService extensionService: IExtHostExtensionService, @IExtHostConfiguration configurationService: IExtHostConfiguration, @IExtHostTerminalService private _terminalService: IExtHostTerminalService, <ins> @IExtHostTerminalShellIntegration private _terminalShellIntegrationService: IExtHostTerminalShellIntegration, </ins> @IExtHostEditorTabs editorTabs: IExtHostEditorTabs, @IExtHostVariableResolverProvider variableResolver: IExtHostVariableResolverProvider, @IExtHostCommands commands: IExtHostCommands,

Related discussion:
text: My VScode and Cursor are broken since today's update. I can't use 'Run and debug', it doesn't open a terminal for my web app runs. Only runs work. VS Code Version: 1.93.0 OS Version: MacOS 14.6.1 (23G93)
I have the same issue when trying to run and debug my Electron application. When I change to (or remove since is the default value) I can use 'Run and debug' again. I won't get the output of the main process (only the renderer process), but at least it's working for now.
same here, this launch configuration fails to start on macos when using or . it only works if you have or remove the console configuration. VS Code Version: 1.93.1 OS Version: MacOS Sonoma 14.6.1 Demo:
Exactly the same issue with nx and nest, also for some strange reason the breakpoints are marked as attached (red) even when no process is running. Something definitely was broken in the last version, this was working fine a few days ago. Not happening on WSL2.
were there any terminal-relate changes here? The on the debug side didn't change in the last release. (Or is there a better way to do things side from a 1s timeout now that shell integration is smart?)
I'm experiencing the same issues; I can't debug anything in NodeJS/TypeScript. This started happening after I updated to MacOS Sequoia. The only way to make it work is if I set the value to the property in the . However, that's not the desired behavior. After a few hours of testing, I managed to make it work —although it's not the ideal solution— by adding the property with the value . Additionally, I with the value . In summary, I have the following configuration:
Your case probably duplicates
Nothing comes to mind around recent changes to terminal launch, apart from a different path for SI scripts. The better way to run command is to use shell integration is it's available. There's no helper function for it just yet though. do you know what that issue was we were discussing a helper?
<!-- 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.
Code change:
@IExtHostExtensionService extensionService: IExtHostExtensionService, @IExtHostConfiguration configurationService: IExtHostConfiguration, @IExtHostTerminalService private _terminalService: IExtHostTerminalService, <ins> @IExtHostTerminalShellIntegration private _terminalShellIntegrationService: IExtHostTerminalShellIntegration, </ins> @IExtHostEditorTabs editorTabs: IExtHostEditorTabs, @IExtHostVariableResolverProvider variableResolver: IExtHostVariableResolverProvider, @IExtHostCommands commands: IExtHostCommands,

Related discussion:
text: 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!
Looks like it's solved. Waiting for the official release so Vscode + Cursor will be fixed.
fyi I think cursor is quite a bit behind vscode so I would not expect it to be fixed there soon
Weird, the issue was immediate on both ides a week ago.
Marking as verified due to confirmation.
Code change:
return; // already initialized } <del> const quality = env.quality || 'stable'; let feedUrl = UpdateManager.getUpdateFeedUrl(quality); </del> <ins> const channel = UpdateManager.getUpdateChannel(); const feedUrl = UpdateManager.getUpdateFeedUrl(channel); </ins> if (!feedUrl) { return; // updates not available } <del> this._channel = quality; </del> <ins> this._channel = channel; </ins> this._feedUrl = feedUrl; this.raw.setFeedURL(feedUrl);

Related discussion:
text: Users that don't want automatic updates should still be given the opportunity to stay in the same version. ping
Code change:
set -e node build/azure-pipelines/common/listNodeModules.js .build/node_modules_list.txt mkdir -p .build/node_modules_cache <del> tar -cvzf .build/node_modules_cache/cache.tgz --files-from .build/node_modules_list.txt </del> <ins> tar -czf .build/node_modules_cache/cache.tgz --files-from .build/node_modules_list.txt </ins> condition: and(succeeded(), ne(variables.NODE_MODULES_RESTORED, 'true')) displayName: Create node_modules archive

Related discussion:
text: A similar error has appeared for other Azure Pipelines tasks
Odd: one is about extracting first one shows no error at all (copy paste mistake?) second one is about creating a zip
This might actually be a bug on AZDO:
And we might be hitting it due to logging every single file. Let's stop doing that.
I reran the failure for the first one which is why it no longer shows an error here's the precise link to the failure
Thanks!
Code change:
export const allApiProposals = Object.freeze({ authSession: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.authSession.d.ts', codiconDecoration: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.codiconDecoration.d.ts', <del> commentsResolvedState: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.commentsResolvedState.d.ts', </del> contribCommentEditorActionsMenu: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.contribCommentEditorActionsMenu.d.ts', contribCommentPeekContext: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.contribCommentPeekContext.d.ts', contribCommentThreadAdditionalMenu: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.contribCommentThreadAdditionalMenu.d.ts',

Related discussion:
text: <!-- 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 comments API doesn't have the concept of resolved/unresolved threads, although most code review tools distinguish them. The current API allows us to surface this to the users, see However, this seems pretty limited. I find it difficult to identify all my unresolved comments. It's very easy to miss some of them. If the API had a boolean for unresolved comments, we could surface them in multiple ways: In the Comments panel, surface the number of unresolved comments, similar to what is done with Problems: ! In the Comments panel, highlight the unresolved comments (or put them in bold), so that it's obvious to the user what comments they still have to go through. In the Comments panel, have a way to hide/filter the resolved comments. In the Editor, consider consider using a different background color for unresolved comments. I currently use a different label for unresolved comments, but this is very subtle. In the gutter, use a different symbol for unresolved comments (e.g. or a diamond of another color). In the Editor, provide a way to go to the next unresolved comment (an alternative to ).
Let's discuss the API change. IMO, the information should be part of a . On many levels, Comments seem similar to s. A diagnostic is a comment provided by a tool such as a compiler. A comment is typically provided by a human. Diagnostics have a severity field, which indicates how important is the problem. We need an equivalent for Comments, something that tells the user if an action is expected (e.g. they need to resolve it) or not. Once the user addresses the comment, the importance is reduced. simplistic solution is to add a boolean, e.g. . to , we can go for a two-state enum instead: to be more general: . We might consider having more fields here. In a code review, multiple users interact with the comments. The current VSCode user is not necessarily the person who needs to do something. For example, the user has just updated the comment and they wait for a response.
Code change:
export const allApiProposals = Object.freeze({ authSession: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.authSession.d.ts', codiconDecoration: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.codiconDecoration.d.ts', <del> commentsResolvedState: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.commentsResolvedState.d.ts', </del> contribCommentEditorActionsMenu: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.contribCommentEditorActionsMenu.d.ts', contribCommentPeekContext: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.contribCommentPeekContext.d.ts', contribCommentThreadAdditionalMenu: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.contribCommentThreadAdditionalMenu.d.ts',

Related discussion:
text: So the third value could be used to mean "it's not my turn" or "acknowledged, I'll come back later". The benefit is that the user can use the list of "unresolved" issues as a TODO-list and publish the comments once it's empty.
Thank you very much for your proposal. and me have quickly discussed this and we believe this proposal makes good sense. We plan to start looking into it next milestone. Though no promises yet when this will land, we will know more in December when we start our investigation.
All of the proposals in have merit. In a perfect world I would choose one of options 2 or 4; however, we have users of the comments API who's comments don't have a resolved/unresolved state. Option 3 circumvents that, but then we have the issue of what to show in the UI: a GitHub PR comment isn't high or low priority. Another proposal, similar to how comment reactions work:
I see than left comments on the commit (). I like the approach of having an object for the state (instead of the proposed boolean/enum), it gives more flexibility and lets user create their own states. In my proposal, the information was attached to a thread, not to a single comment. Do we have use-cases where we want this information per comment? We might also want to control the gutter icon:
GitHub comments are resolved per-thread, so no, no cases were we want it per comment. I'll move it to the thread.
After much discussion, we have decided to proceed with the following: The main reasoning behind this is that resolved vs. unresolved comments should look the same to the user across a GitHub PR extension, an Azure Dev Ops PR extensions, and any other PR extension. There original concern around using "resolved" and "unresolved" is that maybe not all comment provider have those states (maybe they have "viewed" and "unviewed" states for example). To alleviate this, we'll see if we can avoid using "resolved"/"unresolved" language in the UI. If additional states are needed later, we can always add more to the API.
I have a basic implementation of this working, with and themable colors. Before I finish up the pull request to send it out, I was wondering what the best practice is for providing defaults for these colors?
Code change:
export const allApiProposals = Object.freeze({ authSession: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.authSession.d.ts', codiconDecoration: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.codiconDecoration.d.ts', <del> commentsResolvedState: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.commentsResolvedState.d.ts', </del> contribCommentEditorActionsMenu: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.contribCommentEditorActionsMenu.d.ts', contribCommentPeekContext: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.contribCommentPeekContext.d.ts', contribCommentThreadAdditionalMenu: 'https://raw.githubusercontent.com/microsoft/vscode/main/src/vscode-dts/vscode.proposed.contribCommentThreadAdditionalMenu.d.ts',

Related discussion:
text: In the mocks from we use a yellow for unresolved comments that is inspired by visuals of our internal tool. I am not sure if they match an established VS Code palette.
awesome, looking forward to reviewing it! Generally, we try to avoid introducing a new color entirely for something like this. The best practice would be to look through the existing color values where we use yellow then use the same yellow, just like is done here where uses the same color as : We'll also do a UX review of this, so the color may end up changing anyway.
I went for new colors as the comments are conceptually something different than e.g. editor warnings. Currently the comments in the editor use (default blue), so a theme, an extension, or the users themselves would not be able to style comments independently of peek views. I think it makes sense to base the default on another color like as in your example, so that themes which omit the new colors receive a reasonable default, but it seems like we would give up a lot of flexibility and also clarity if comment widget colors directly used something like internally?
Yes, basing the color on another is what I meant! I agree that we don't want to directly use another theme color.
If anyone is eager for this API to be finalized then please comment and let me know how it's working for you. Otherwise, I will plan to finalize later in 2022.
This would be very nice to have. We are using Github and especially larger PRs are hard to manage, if there are many comments (in Github as well as in VSCode)
So is there currently a way to filter resolved/unresolved comments in the sidebar? If not what can I modify currently to provide a visual distinction between resolved/unresolved?
there's a color difference on the icon, but that's currently it. This is the feature request you're looking for
Code change:
// reset selection to placeholder session.next(); <del> assert.equal(session.isSelectionWithinPlaceholders(), false); </del> <ins> assert.equal(session.isSelectionWithinPlaceholders(), true); </ins> assert.equal(session.isAtLastPlaceholder, true); assertSelections(editor, new Selection(1, 13, 1, 13), new Selection(2, 17, 2, 17)); });

Related discussion:
text: <!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.33.1 OS Version: Windows_NT x64 10.0. Steps to Reproduce: a new user snippet file for the project. The one I encounter the issue with is: the snippet and attempt to press TAB after writing the first variable cursor does not move to the next stop, instead a tab character is The desired behavior would be for the cursor to move to the next tab stop. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
Seems to work just fine for me... Any special keybinding or setting? !
The action you took is not the problem I encounter and does indeed work the same way for me. Could you try to edit "SystemName", the first tab stop, then press TAB to go to "Required Components"? vsCode just inserts a tab character after whatever I wrote instead of going to the next tab stop.
Ok, thanks for clarifying. For some reason snippet mode stops when making that edit... Not sure why
I have encountered similar issue, however, I could add a single blank space in the snippet which "fixed" the tab navigation. Also, my example is far simpler. See
This is a regression from I will revert that change and re-open the corresponding issue (which is much more rare than these issues)
Thank you for fixing this, looking forward to the next release.
Code change:
* Defaults to true. */ sticky?: boolean; <ins> /** * Should the hover be shown below the line if possible? * Defaults to false. */ below?: boolean; </ins> } /**

Related discussion:
text: Issue Type: <bFeature Request</bI want the message could display under the variables it refers to. Because the message box blocks the code over the current line. Thank you. VS Code version: Code 1.36.1 (, 2019-07-08T22:59:35.033Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
Can we just change the default to or does this require a setting?
Kind of feel like this is out of scope, but I don't think this should be assigned to me since it's regarding monaco.
Actually I was wrong - it is determined by : I verified if I swap the order then the hovers appear below instead of above (where there's space). I'll make a PR.
Done! Before: <img width="734" alt="Screenshot 2021-06-30 at 08 45 06" src="https://user-"Change the setting: <img width="921" alt="Screenshot 2021-06-30 at 08 45 14" src="https://user-"After: <img width="777" alt="Screenshot 2021-06-30 at 08 45 22" src="https://user-"
Let's continue tracking in
Code change:
"browser": "./dist/browser/cssServerMain", "dependencies": { "vscode-css-languageservice": "^6.0.1", <del> "vscode-languageserver": "^8.0.1", </del> <ins> "vscode-languageserver": "^8.0.2-next.4", </ins> "vscode-uri": "^3.0.3" }, "devDependencies": {

Related discussion:
text: Version: 1.68.0-insider Commit: Date: 2022-06-02T05:17:01.962Z open the Settings JSON editor add some unnecessary commas no problems reported in the problems view. open the JSON Language Server log. Observe that there are no diagnostic requests. Other requests are sent and completed, so the language server is running.
Maybe unrelated: I was expecting "trailing comma" warnings in (we recently changed the schema to not accept them), but they only started showing after I flushed the schema cache (using the UI command) and reloaded the window (I can't completely rule out that a window reload alone would have helped).
I checked that with the fix the trailing commas are reported
Code change:
disturl "https://electronjs.org/headers" <del> target "22.3.5" </del> <ins> target "22.3.6" </ins> runtime "electron" build_from_source "true"

Related discussion:
text: This works on web e.g. but does not work in desktop, either with a desktop git clone or with RemoteHub. The last time this happened it was due to a regression in the list of enabled codecs for our Electron builds.
Sorry for the breakage, the changes from has not been to Electron = 22 versions yet. It will be addressed in new builds this week.
Addressed in
Reopening because of
Code change:
"@vscode/iconv-lite-umd": "0.7.0", "@vscode/policy-watcher": "^1.1.4", "@vscode/proxy-agent": "^0.14.1", <del> "@vscode/ripgrep": "^1.15.4", </del> <ins> "@vscode/ripgrep": "^1.15.5", </ins> "@vscode/spdlog": "^0.13.10", "@vscode/sqlite3": "5.1.6-vscode", "@vscode/sudo-prompt": "9.3.1",

Related discussion:
text: From Probably a regression from making aarch64-linux ripgrep build statically compiled to fix We might need to dynamically compile ripgrep instead of using musl, and find a container to compile it in. related // cc
Looks like jemalloc just needs to be configured with to support 16K page size. This can be achieved by setting the environment variable: (16K page size) Or to support 64K page size as well: (64K page size) In either case, it'd still work for 4K/16K(/64K) page sizes.
Do we have any good news on this? I found the similar thing happened before on other application like , probably we can use the same approach to solve this one?
Any update on this issue ?
Temporary Workaround: To address the issue until it is fixed, follow these steps: Install ripgrep and obtain its path. For Rocky Linux or any RHEL-based Linux distribution, run the following command with root privileges: For Ubuntu, use the following command: Alternatively, you can install ripgrep using Cargo: Verify the installation and retrieve the path by running: Replace the broken rg with a symlink by executing the following script. Please note that you should remove the echo commands to commit the changes: This workaround should help resolve the issue temporarily.
This should be fixed in tomorrow's VS Code Insiders. Please try it out and let me know if it works for you!
I tried but it seems not fixed or not included the fix. execute from the remote server(aarch64) and got <jemalloc: Unsupported system page size <jemalloc: Unsupported system page size memory allocation of 5 bytes failed find: ‘.vscode-server-insiders/bin//nodemodules/ terminated by signal 6 (after resetting the remote environment by deleting .vscode-server-insiders folder on the remote, and vscode reloaded. - 'Developer: Reload Window')
Are you running 16K page size or 64K?
I got $ getconf PAGESIZE on the aarch64 remote (Rocky Linux 8, aws r7g instance/Graviton3 processors).
Code change:
"@vscode/iconv-lite-umd": "0.7.0", "@vscode/policy-watcher": "^1.1.4", "@vscode/proxy-agent": "^0.14.1", <del> "@vscode/ripgrep": "^1.15.4", </del> <ins> "@vscode/ripgrep": "^1.15.5", </ins> "@vscode/spdlog": "^0.13.10", "@vscode/sqlite3": "5.1.6-vscode", "@vscode/sudo-prompt": "9.3.1",

Related discussion:
text: Meanwhile, executing the same command above on x86-64 remote, I got the normal rg help print out as like error: The following required arguments were not provided: and correcting the hand typed typo above of vscode insider version info Version: 1.79.0-insider (user setup) Commit: Date: 2023-05-19T20:39:14.598Z Electron: 22.5.2 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: WindowsNT x64 10.0.
Hmm ok. I tried setting the env variable to increase max page size for jemalloc, but it seems to not be working. I'll try another approach.
If you let me know what you are attempting, I can also try out some stuff. Page size here is
Is this fixed in the latest release version of VScode? I just check on my arm64 container but it seems not working. VScode Version: 1.79.0 (Universal)
Same with Switched to newest insider build. . Problem not solved. Went to server, killed and deleted . Tried again to bootstrap. Problem is still NOT resolved. Search is still limited to open files.
!
Here is some useful link detailing what I think is the problem. Not sure if it is resolved by now. But if info from the discussion is current, I think you will have to either compile on the target system, or ship different precompiled versions of binary and select the correct one depending on the system specs (see ).
We do cross-compile for different systems for ripgrep I'll have to take another look.
So, my interpretation is, that the page-size is hard-coded into jemalloc. When the system page size at runtime differs from the one it is compiled for, it will fail. In other words, the one shipped right now fails out of the box: From your linked repo, I understand that you now focus on 16k page size. That would also not help me (if my suspicion is right), as my system's page size is: 64k
: Temporary fix. Bootstrap on target ARM system. You should have a directory called now. That is where the vscode server lives.