jiebi/CodeConvo huggingface dataset:
Code change:
builtin return fi <ins> # Disable shell integration if HISTCONTROL is set to erase duplicate entries as the exit code # reporting relies on the duplicates existing if [[ "$HISTCONTROL" =~ .*erasedups.* ]]; then builtin unset VSCODE_SHELL_INTEGRATION builtin return fi </ins> if [ -z "$VSCODE_SHELL_INTEGRATION" ]; then builtin return fi

Related discussion:
text: jupyter-keymap1.0.0 jupyter-renderers1.0.8 hexeditor1.9.6 powershell2022.5.1 remote-repositories0.12.0 vscode-js-profile-flame1.0.2 vsliveshare1.0.5615 vsliveshare-pack0.4.0 resourcemonitor1.0.7 vscode-commons0.0.6 vscode-yaml1.8.0 sass-indented1.5.1 gitconfig2.0.1 mdx0.1.0 codevalet-vscode1.5.0 vcl0.1.2 msbuild-project-tools0.4.3 jest-snapshot-language-support1.1.1 intellicode-api-usage-examples0.1.1 vscodeintellicode1.2.21 vscode-icons11.12.0 quokka-vscode1.0.478 wallaby-vscode1.0.338 jinja0.0.8 ReactSnippets2.4.0 vscode-proto30.5.5 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
It's working fine for me (I have the icon customized): <img width="447" alt="Screen Shot 2022-06-10 at 11 29 56 am" src="https://user-"This is with a fresh install of stable bash-git-prompt Version: 1.69.0-insider Commit: Date: 2022-06-10T05:16:48.648Z Electron: 17.4.7 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Darwin x64 21.5.0 Could you see if it happens on the ?
I am installing the Insiders build now. I will let you know.
Hmmm, doesn't seem to work. <img width="232" alt="image" src="https://user-"
How does it detect the exit code? Perhaps I have something installed that is interfering, either in my bash config or elsewhere?
Yeah it's meant to change depending on the exit code of the program.
Code change:
builtin return fi <ins> # Disable shell integration if HISTCONTROL is set to erase duplicate entries as the exit code # reporting relies on the duplicates existing if [[ "$HISTCONTROL" =~ .*erasedups.* ]]; then builtin unset VSCODE_SHELL_INTEGRATION builtin return fi </ins> if [ -z "$VSCODE_SHELL_INTEGRATION" ]; then builtin return fi

Related discussion:
text: Some info that would help us investigate: Set log level to debug via the command palette, then in Help Developer Tools console it will show some shell integration related logs when you run a command Do you set PROMPT_COMMAND anywhere? Do you use bash-preexec?
I'll get this going and let you know. Ah yes, besides using , I have this in my bash config: I'll try disabling that and see what happens. It would be a shame to lose it but perhaps there's a better way of implementing that so that it's compatible, if that turns out to be the issue. Not that I am aware of, no.
OK, so I disabled my PROMPT_COMMAND change and tried a few things in a new terminal that weren't working before. Now, when I use it is still an empty circle, but when I do , I get the green success lozenge!! So I'm guessing that was the main issue; though I do wonder if I should be seeing that green circle for and such too (that said, this is the non-Insiders build - I'll try Insiders in a second). I'll add the log level and see what I get.
I can confirm that the Insiders build works as advertised now, so it was my history manipulation code that was getting in the way. Thank you for helping out. I'll close this issue as it appears to be an issue on my side, not yours. Thank you for helping troubleshoot.
Let's keep this open to track the issue so we handle it better.
would you like me to gather the logging info as requested, since this is staying open?
I think we understand the problem enough to reproduce it, it's just a case we need to detect and handle better.
This is happening because we actually depend on to differentiate regular commands that succeeded or failed vs ones exited via or running an empty line. Specifically this call: I'll disable shell integration if includes as that specifically is the reason it was failing.
<!-- 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!
Code change:
builtin return fi <ins> # Disable shell integration if HISTCONTROL is set to erase duplicate entries as the exit code # reporting relies on the duplicates existing if [[ "$HISTCONTROL" =~ .*erasedups.* ]]; then builtin unset VSCODE_SHELL_INTEGRATION builtin return fi </ins> if [ -z "$VSCODE_SHELL_INTEGRATION" ]; then builtin return fi

Related discussion:
text: To verify: In set Enable the shell integration Open a terminal, it should not have shell integration enabled
/verified I see that the integration is not enabled as the lozenges are missing.
Code change:
import { ExtHostDocuments } from 'vs/workbench/api/common/extHostDocuments'; import * as extHostTypeConverter from 'vs/workbench/api/common/extHostTypeConverters'; import * as types from 'vs/workbench/api/common/extHostTypes'; <del> import { checkProposedApiEnabled } from 'vs/workbench/services/extensions/common/extensions'; </del> import type * as vscode from 'vscode'; import { ExtHostCommentsShape, IMainContext, MainContext, CommentThreadChanges, CommentChanges } from './extHost.protocol'; import { ExtHostCommands } from './extHostCommands';

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:
import { ExtHostDocuments } from 'vs/workbench/api/common/extHostDocuments'; import * as extHostTypeConverter from 'vs/workbench/api/common/extHostTypeConverters'; import * as types from 'vs/workbench/api/common/extHostTypes'; <del> import { checkProposedApiEnabled } from 'vs/workbench/services/extensions/common/extensions'; </del> import type * as vscode from 'vscode'; import { ExtHostCommentsShape, IMainContext, MainContext, CommentThreadChanges, CommentChanges } from './extHost.protocol'; import { ExtHostCommands } from './extHostCommands';

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:
import { ExtHostDocuments } from 'vs/workbench/api/common/extHostDocuments'; import * as extHostTypeConverter from 'vs/workbench/api/common/extHostTypeConverters'; import * as types from 'vs/workbench/api/common/extHostTypes'; <del> import { checkProposedApiEnabled } from 'vs/workbench/services/extensions/common/extensions'; </del> import type * as vscode from 'vscode'; import { ExtHostCommentsShape, IMainContext, MainContext, CommentThreadChanges, CommentChanges } from './extHost.protocol'; import { ExtHostCommands } from './extHostCommands';

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:
assertLink( '(see http://foo.bar)', <del> '     http://foo.bar ' </del> <ins> '     http://foo.bar  ' </ins> ); assertLink( '[see http://foo.bar]', <del> '     http://foo.bar ' </del> <ins> '     http://foo.bar  ' </ins> ); assertLink( '{see http://foo.bar}', <del> '     http://foo.bar ' </del> <ins> '     http://foo.bar  ' </ins> ); assertLink( '<see http://foo.bar>', <del> '     http://foo.bar ' </del> <ins> '     http://foo.bar  ' </ins> ); assertLink( '<url>http://mylink.com</url>',

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.75.1 OS Version: Windows 11 Steps to Reproduce: a link in the terminal of the form the link would be automatically detected correctly and made clickable (although in the debug tab, by contrast, it was not detected properly). version 1.75.0, the link detection wrongly terminates at the so the link cannot be easily clicked to open it. I appreciate that you can never please all the people all the time with URL guessing, but I thought it was worth mentioning given that it used to work fine, and to be fair all the characters , and are standard normal URL code points and always have been.
Can repro after, not before: !
This is actually a regression in monaco's link detection which the terminal leverages for uris: 74: <img width="259" alt="image" src="https://user-"75: ! So this was unrelated to the recent terminal link improvements which focused on file detection
introduced this change to fix
Commas are used pretty often in certain links, not sure how advanced the detection is but it could be improved by only treating it as a separator if after a / or if the word before has a period?
GitHub also doesn't split at comma: , I'd probably revert the fix, but I'm fine with either. Up to you
This issue doesn't just affect the links in the terminal. It also applies to , and files (and maybe more).
Code change:
assertLink( '(see http://foo.bar)', <del> '     http://foo.bar ' </del> <ins> '     http://foo.bar  ' </ins> ); assertLink( '[see http://foo.bar]', <del> '     http://foo.bar ' </del> <ins> '     http://foo.bar  ' </ins> ); assertLink( '{see http://foo.bar}', <del> '     http://foo.bar ' </del> <ins> '     http://foo.bar  ' </ins> ); assertLink( '<see http://foo.bar>', <del> '     http://foo.bar ' </del> <ins> '     http://foo.bar  ' </ins> ); assertLink( '<url>http://mylink.com</url>',

Related discussion:
text: VS Code Version: 1.75.1 OS Version: Windows 10 Steps to reproduce: a file and paste the following code into it: an file and paste the following url into it: . both cases the link detection wrongly terminates at the so the link cannot be easily clicked to open it.
:+1: I'm OK to revert.
Code change:
import { KeybindingWeight } from 'vs/platform/keybinding/common/keybindingsRegistry'; import { ILogService } from 'vs/platform/log/common/log'; import { SnippetSession } from './snippetSession'; <del> import { EditorState, CodeEditorStateFlag } from 'vs/editor/browser/core/editorState'; </del> export class SnippetController2 implements IEditorContribution {

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:
// Filename not allowed this.filePickBox.validationMessage = nls.localize('remoteFileDialog.validateBadFilename', 'Please enter a valid file name.'); return Promise.resolve(false); <del> } else if (!statDirname || !statDirname.isDirectory) { </del> <ins> } else if (!statDirname) { </ins> // Folder to save in doesn't exist <ins> const message = nls.localize('remoteFileDialog.validateCreateDirectory', 'The folder {0} does not exist. Would you like to create it?', resources.basename(resources.dirname(uri))); return this.yesNoPrompt(uri, message); } else if (!statDirname.isDirectory) { </ins> this.filePickBox.validationMessage = nls.localize('remoteFileDialog.validateNonexistentDir', 'Please enter a path that exists.'); return Promise.resolve(false); }

Related discussion:
text: Maybe you've already thought about this but it would be useful to be able to create a new folder in the simplified file dialog. This could be a button in the title bar or a confirmation step when a folder that doesn't exist was typed. Creating a folder and opening it, and creating a folder and saving a file in it, are common workflows so it would be useful to be able to do those in one step.
For the meantime:
Hey thanks for the mention! This was a feature I personally needed for quite some time - we all basically do those steps mentioned by on a daily basis so I decided to code an extension for it. Even though the extension already works great, I am actually working on it right now and adding a new feature which will allow it to create new folders using the Simple file dialogs - regardless of user setting, see . If anyone's interested, I think I'll manage to finish it by tomorrow.
I've been busy with work and other projects but after a long wait, I worked really hard and managed to finish my npm module for Visual Studio Code that implements the aforementioned behavior and shows a custom QuickPick that allows browsing and creating folders from the Command Palette, even nested/recursive folders. The extension that implements this package is available at repo. Not perfect (yet) but it works.
Also create new file in Open File dialog would be useful.
Saving is good. Opening hasn't been implemented -- should there be a new issue for that?
Code change:
// Filtered "new extensions" button if (element instanceof SettingsTreeNewExtensionsElement) { <del> if ((this.viewState.tagFilters && this.viewState.tagFilters.size) || this.viewState.filterToCategory) { </del> <ins> if (this.viewState.tagFilters?.size || this.viewState.filterToCategory) { </ins> return false; } }

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:
private onTabFocusModeChange(): void { const info: StateDelta = { type: 'tabFocusMode', tabFocusMode: TabFocus.getTabFocusMode(this.contextKeyService.getContextKeyValue('focusedView') === 'terminal' ? TabFocusContext.Terminal : TabFocusContext.Editor) }; this.updateState(info); }

Related discussion:
text: Testing an editor and write something in it. tab until you reach the terminal. Type something in the terminal. . Realize that tab is correctly not moving focus in the terminal. command "Toggle Tab Key Moves Focus" out of the terminal and keep tabbing until you get back to your editor. something in the editor. again until you reach the terminal. something in the terminal. to tab out of the terminal. It looks like tab moves focus as toggled itself off. Tab moves focus seems to be off for both terminal and editor at this point until reload.
I can also cause similar behavior if I flip the settings.
what is supposed to happen now? What I think I expect to happen (and isn't happening): If I run "Toggle tab key moves focus" while in a place where it doesn't move focus via setting, then it now globally moves focus. If I run "Toggle tab key moves focus" while in a place where it does move focus, then it now globally does not move focus. However, I'm not a "tab moves focus" user, so maybe my expectations are bogus.
Thank you for testing. Those expectations are correct, except that the toggling does not apply globally - it is per area. So, if I have in settings: terminal tab focus mode: on editor tab focus mode: off where: = status bar indicator = no status bar indicator focus the terminal focus the editor focus the terminal and toggle it off focus the editor and toggle it on focus the terminal focus the editor reload the window and focus the terminal focus the editor I see that this is not working atm because I'm not reacting to configuration changes
fyi for easier testing since the command palette can cause the terminal to no longer be focused, I'd suggest using the keybinding to toggle tab focus mode
Code change:
"@vscode/policy-watcher": "^1.1.4", "@vscode/proxy-agent": "^0.18.2", "@vscode/ripgrep": "^1.15.9", <del> "@vscode/spdlog": "^0.13.12", </del> <ins> "@vscode/spdlog": "^0.14.0", </ins> "@vscode/sqlite3": "5.1.6-vscode", "@vscode/sudo-prompt": "9.3.1", "@vscode/vscode-languagedetection": "1.0.21",

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.85.1 OS Version: Alpine 3.19 Steps to Reproduce: More info and fix in new version :