jiebi/CodeConvo huggingface dataset:
Code change:
if (lens.command) { const title = renderLabelWithIcons(lens.command.title.trim()); if (lens.command.id) { <del> children.push(dom.$('a', { id: String(i) }, ...title)); </del> <ins> children.push(dom.$('a', { id: String(i), title: lens.command.tooltip }, ...title)); </ins> this._commands.set(String(i), lens.command); } else { <del> children.push(dom.$('span', undefined, ...title)); </del> <ins> children.push(dom.$('span', { title: lens.command.tooltip }, ...title)); </ins> } if (i + 1 < lenses.length) { children.push(dom.$('span', undefined, 'u00a0|u00a0'));

Related discussion:
text: <!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- 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.52.1 OS Version: Windows 10 1909 Steps to Reproduce: then press to run extension any folder with some code. code lens show, then hover one of codelens. Actual Result: ! Is this an expected behavior of vscode extension? Or is there any configation to show it?
I believe this is expected behavior, however forwarding to so he can close
Yes. what tooltip to you expect when hovering over a code lens?
As , show maybe suitable I think.
Ah, I see. That actually makes sense and would be a simple change
Can I take a look at this issue and try to work on this?
This is where the dom-nodes for codelens are created: Using the title attribute on them should do the job
Is the native tooltip sufficient for the fix? Windows & MacOS :-------------------------: <img src="https://user-" width="400"Windows | MacOS :-------------------------:|:-------------------------: <img src="https://user-" width="400"| <img src="https://user-" width="400"
Code change:
this.root.children = this.root.children .filter(child => child instanceof SettingsTreeSettingElement && child.matchesAllTags(this._viewState.tagFilters) && child.matchesScope(this._viewState.settingsTarget, isRemote) && child.matchesAnyExtension(this._viewState.extensionFilters) && child.matchesAnyId(this._viewState.idFilters) && child.matchesAnyFeature(this._viewState.featureFilters) && child.matchesAllLanguages(this._viewState.languageFilter)); <del> if (this.newExtensionSearchResults && this.newExtensionSearchResults.filterMatches.length) { const resultExtensionIds = this.newExtensionSearchResults.filterMatches </del> <ins> if (this.newExtensionSearchResults?.filterMatches.length) { let resultExtensionIds = this.newExtensionSearchResults.filterMatches </ins> .map(result => (<IExtensionSetting>result.setting)) .filter(setting => setting.extensionName && setting.extensionPublisher) .map(setting => `${setting.extensionPublisher}.${setting.extensionName}`); <ins> resultExtensionIds = arrays.distinct(resultExtensionIds); </ins> <del> const newExtElement = new SettingsTreeNewExtensionsElement('newExtensions', arrays.distinct(resultExtensionIds)); newExtElement.parent = this._root; this._root.children.push(newExtElement); </del> <ins> if (resultExtensionIds.length) { const newExtElement = new SettingsTreeNewExtensionsElement('newExtensions', resultExtensionIds); newExtElement.parent = this._root; this._root.children.push(newExtElement); } </ins> } }

Related discussion:
text: Testing settings UI for " fontsize" "Show matching extensions" blue button no it - no effect fyi !
It shouldn't show up when the filter is present, I guess
Code change:
if (--existing.refcount <= 0) { existing.value.then(tunnel => tunnel.dispose()); this._tunnels.delete(tunnel.tunnelRemotePort); <del> this._onTunnelClosed.fire(tunnel.tunnelRemotePort); </del> } <ins> } else { tunnel.dispose(); this._onTunnelClosed.fire(tunnel.tunnelRemotePort); </ins> } } };

Related discussion:
text: Refs: x, open our in a docker container with node10 install, open debug viewlet create a by clicking on the launch gear and press debug start a port 3000 to your localhost 3000. Hit the port locally and notice how you get the application Forwarding port 3000 a port localy and notice that you still get the application even though you stopped the forwarding :bug:
Code change:
https-proxy-agent "^5.0.0" proxy-from-env "^1.1.0" <del> "@vscode/ripgrep@^1.15.4": version "1.15.4" resolved "https://registry.yarnpkg.com/@vscode/ripgrep/-/ripgrep-1.15.4.tgz#ca8946b5580bbea1e706ed8d3b1eed5f0d551ab6" integrity sha512-+EPIS2aoD95MFLrgGHd/D2fck42aMRV2cBrT7BiNvKBeSyCTybSaTJ+PGQf6zV/95AhaXHHYqYPVRk3DZoGU9w== </del> <ins> "@vscode/ripgrep@^1.15.5": version "1.15.5" resolved "https://registry.yarnpkg.com/@vscode/ripgrep/-/ripgrep-1.15.5.tgz#26025884bbc3a8b40dfc29f5bda4b87b47bd7356" integrity sha512-PVvKNEmtnlek3i4MJMaB910dz46CKQqcIY2gKR3PSlfz/ZPlSYuSuyQMS7iK20KL4hGUdSbWt964B5S5EIojqw== </ins> dependencies: https-proxy-agent "^5.0.0" proxy-from-env "^1.1.0"

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:
https-proxy-agent "^5.0.0" proxy-from-env "^1.1.0" <del> "@vscode/ripgrep@^1.15.4": version "1.15.4" resolved "https://registry.yarnpkg.com/@vscode/ripgrep/-/ripgrep-1.15.4.tgz#ca8946b5580bbea1e706ed8d3b1eed5f0d551ab6" integrity sha512-+EPIS2aoD95MFLrgGHd/D2fck42aMRV2cBrT7BiNvKBeSyCTybSaTJ+PGQf6zV/95AhaXHHYqYPVRk3DZoGU9w== </del> <ins> "@vscode/ripgrep@^1.15.5": version "1.15.5" resolved "https://registry.yarnpkg.com/@vscode/ripgrep/-/ripgrep-1.15.5.tgz#26025884bbc3a8b40dfc29f5bda4b87b47bd7356" integrity sha512-PVvKNEmtnlek3i4MJMaB910dz46CKQqcIY2gKR3PSlfz/ZPlSYuSuyQMS7iK20KL4hGUdSbWt964B5S5EIojqw== </ins> dependencies: https-proxy-agent "^5.0.0" proxy-from-env "^1.1.0"

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.
Code change:
https-proxy-agent "^5.0.0" proxy-from-env "^1.1.0" <del> "@vscode/ripgrep@^1.15.4": version "1.15.4" resolved "https://registry.yarnpkg.com/@vscode/ripgrep/-/ripgrep-1.15.4.tgz#ca8946b5580bbea1e706ed8d3b1eed5f0d551ab6" integrity sha512-+EPIS2aoD95MFLrgGHd/D2fck42aMRV2cBrT7BiNvKBeSyCTybSaTJ+PGQf6zV/95AhaXHHYqYPVRk3DZoGU9w== </del> <ins> "@vscode/ripgrep@^1.15.5": version "1.15.5" resolved "https://registry.yarnpkg.com/@vscode/ripgrep/-/ripgrep-1.15.5.tgz#26025884bbc3a8b40dfc29f5bda4b87b47bd7356" integrity sha512-PVvKNEmtnlek3i4MJMaB910dz46CKQqcIY2gKR3PSlfz/ZPlSYuSuyQMS7iK20KL4hGUdSbWt964B5S5EIojqw== </ins> dependencies: https-proxy-agent "^5.0.0" proxy-from-env "^1.1.0"

Related discussion:
text: Download and compile : Replace binary deployed by with custom compiled version. Now search should work as expected.
can you check if the following runs fine on your aarch64 setup ? The build is generated from to use 64k for jemalloc.
Thanks built from source works for me!
can any of you verify this:
I untar-ed the file and the binary 'rg' is working good with remote search. (I sym-linked it with vscode 1.79)
<!-- 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!
I can confirm it is fixed with the vscode insider downloaded a minute ago of (assume the commit hash changed since)
thanks so much for checking!
Code change:
} /** <ins> * The state of a comment thread. */ export enum CommentThreadState { Unresolved = 0, Resolved = 1 } /** </ins> * A collection of {@link Comment comments} representing a conversation at a particular range in a document. */ export interface CommentThread {

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:
} /** <ins> * The state of a comment thread. */ export enum CommentThreadState { Unresolved = 0, Resolved = 1 } /** </ins> * A collection of {@link Comment comments} representing a conversation at a particular range in a document. */ export interface CommentThread {

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:
} /** <ins> * The state of a comment thread. */ export enum CommentThreadState { Unresolved = 0, Resolved = 1 } /** </ins> * A collection of {@link Comment comments} representing a conversation at a particular range in a document. */ export interface CommentThread {

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:
max-width: var(--vscode-editor-dictation-widget-width); } <del> .monaco-editor .editor-dictation-widget .codicon.codicon-mic-filled { display: flex; align-items: center; width: 16px; height: 16px; } </del> .monaco-editor .editor-dictation-widget.recording .codicon.codicon-mic-filled { color: var(--vscode-activityBarBadge-background); animation: editor-dictation-animation 1s infinite;

Related discussion:
text: Testing My first reaction for how to stop dictation in the editor was to click the flashing microphone. It would be cool if something happened when the flashing microphone is clicked.
I will turn this into a real with action and hover.
Code change:
.monaco-action-bar .action-item.disabled .action-label, .monaco-action-bar .action-item.disabled .action-label::before, .monaco-action-bar .action-item.disabled .action-label:hover { <del> opacity: 0.6; </del> <ins> color: var(--vscode-disabledForeground); </ins> } /* Vertical actions */

Related discussion:
text: ]- Identify accessibility bugs before check-in and make bug fixing faster and easier. #A11yTCS; #A11ySev2; #DesktopApp; #Win32; #Visual Studio Code Client; #BM-VisualStudioCodeClient-Win32-Jan2024; #WCAG1.4.11; #Non-text Contrast; #A11yWCAG2.1; Visual Studio Code insider version 1.86.0 Microsoft Windows 11 Enterprise (22H2) OS Build .3007 Visual studio insider the Visual Studio Code Marketplace, go to the GitHub Copilot extension page and click Install. a sample code and press CTRL+I to open the Copilot inline chat. that the contrast ratio of focus is on "Make request" button is (1.787:1) which is less than required. While navigating with Keyboard tab key to the "Make request" button the contrast ratio of focus is (1.787:1) which is less than required. While navigating with Keyboard Tab key to "Make request" button the contrast ratio of focus should be greater than or equal to required (3:1). Keyboard users will face difficulty while navigating through keyboard if the focus is not clearly visible to the user and ratio is less than required. !
Verified the issue in below environment: Visual Studio Code Insider Version: 1.87.0-insider (user setup) Issue is not fixed. Please find attachment for reference. Could you please confirm us in which build the fixes will be available. <img width="785" alt="203773_not fixed" src=""
The focus border now has increased contrast and is now the same colour as everywhere else in VS Code. We don't have any indication from users that this accent colour is a problem anywhere in the dark theme.
Code change:
if (!this.environmentService.isBuilt) { onOutput('Building tunnel CLI from sources and run', false); onOutput(`${logLabel} Spawning: cargo run -- tunnel ${commandArgs.join(' ')}`, false); <del> tunnelProcess = spawn('cargo', ['run', '--', 'tunnel', ...commandArgs], { cwd: join(this.environmentService.appRoot, 'cli') }); </del> <ins> tunnelProcess = spawn('cargo', ['run', '--', 'tunnel', ...commandArgs], { cwd: join(this.environmentService.appRoot, 'cli'), stdio }); </ins> } else { onOutput('Running tunnel CLI', false); const tunnelCommand = this.getTunnelCommandLocation(); onOutput(`${logLabel} Spawning: ${tunnelCommand} tunnel ${commandArgs.join(' ')}`, false); <del> tunnelProcess = spawn(tunnelCommand, ['tunnel', ...commandArgs], { cwd: homedir() }); </del> <ins> tunnelProcess = spawn(tunnelCommand, ['tunnel', ...commandArgs], { cwd: homedir(), stdio }); </ins> } tunnelProcess.stdout!.on('data', data => {

Related discussion:
text: Version: 1.78.0-insider (user setup) Commit: Date: 2023-04-04T09:32:52.453Z Electron: 22.4.3 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes run from a Windows command prompt The tunnel starts and prints open VS Code, and open the output Note that the output is stuck at Missing are the message and the info that the tunnel is attached The UI thinks the tunnel is still connecting. Sometimes this also works, but when I try it, most of the time it is stuck
Can you please enable trace logging and share the output?
Nothing extra messages shown when the Desktop tunnel attaches:
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Still a problem in Version: 1.78.0-insider (user setup) Commit: Date: 2023-04-12T05:19:38.288Z Reproduces every time I try it
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
<!-- 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!
I'm still not seeing info in the log in VS Code that the tunnel is attached after from the command line and seeing the "Open this link in your browser". <img width="945" alt="image" src=""
the tunnel will not start unless you "Turn on Remote Tunnel Access"
<img width="730" alt="image" src=""Looks good to me after enabling tunnels in VS Code
Thanks. Enabling Tunnels in VS Code fixed it.