jiebi/CodeConvo huggingface dataset:
Code change:
label?: string; /** <ins> * The optional state of a comment thread, which may affect how the comment is displayed. */ state?: CommentThreadState; /** </ins> * Dispose this comment thread. * * Once disposed, this comment thread will be removed from visible editors and Comment Panel when appropriate.

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:
label?: string; /** <ins> * The optional state of a comment thread, which may affect how the comment is displayed. */ state?: CommentThreadState; /** </ins> * Dispose this comment thread. * * Once disposed, this comment thread will be removed from visible editors and Comment Panel when appropriate.

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:
label?: string; /** <ins> * The optional state of a comment thread, which may affect how the comment is displayed. */ state?: CommentThreadState; /** </ins> * Dispose this comment thread. * * Once disposed, this comment thread will be removed from visible editors and Comment Panel when appropriate.

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:
keybinding: { primary: KeyMod.Alt | KeyCode.KeyR, mac: { primary: KeyMod.CtrlCmd | KeyMod.Alt | KeyCode.KeyR }, <del> when: ContextKeyExpr.or(TerminalContextKeys.focusInAny, TerminalContextKeys.findFocus), </del> <ins> when: TerminalContextKeys.findVisible, </ins> weight: KeybindingWeight.WorkbenchContrib }, precondition: ContextKeyExpr.or(TerminalContextKeys.processSupported, TerminalContextKeys.terminalHasBeenCreated),

Related discussion:
text: Type: <bBug</bAlt+C or Alt+W or Alt+R Now if area with code is in focus, broken search parameter selector will appear without search panel itself. If terminal is in focus, search panel will appear. I think it is completely unneccesary to intercept alt+c globally when no search panel is opened. In my setup it leads to conflict with alt+c fzf's key binding in terminal. VS Code version: Code 1.86.2 (, 2024-02-13T19:41:37.860Z) OS version: Linux x64 6.7.6-arch1-1 Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (19)</summaryExtensionVersion ------ vscode-nginx-conf0.3.2 vscode-cython0.3.10 vscode-docker1.29.0 autopep82023.8.0 debugpy2024.2.0 isort2023.10.1 python2024.2.1 vscode-pylance2024.2.2 jupyter2024.1.1 jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.348.0 cmake-tools1.17.17 cpptools1.19.4 cpptools-extension-pack1.3.0 rust-analyzer0.3.1860 cmake0.0.17 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.87.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
This is feature - it influences bahavior of Add Selection To Next Find Match (<kbdCtrl</kbd+<kbdD</kbd) and Select all occurrences of current selection (<kbdCtrl</kbd+<kbdShift</kbd+<kbdL</kbd). However not sure how regexp is useful here, except it would be applied for next find.
Can you share a screen recording? I'm not sure if I understand what you're talking about.
Code change:
keybinding: { primary: KeyMod.Alt | KeyCode.KeyR, mac: { primary: KeyMod.CtrlCmd | KeyMod.Alt | KeyCode.KeyR }, <del> when: ContextKeyExpr.or(TerminalContextKeys.focusInAny, TerminalContextKeys.findFocus), </del> <ins> when: TerminalContextKeys.findVisible, </ins> weight: KeybindingWeight.WorkbenchContrib }, precondition: ContextKeyExpr.or(TerminalContextKeys.processSupported, TerminalContextKeys.terminalHasBeenCreated),

Related discussion:
text: This video shows the behavior of vscode after pressing alt+c
This video shows what I expected after pressing alt+c in terminal It is configured with following lines in .zshrc:
I can repro when the widget is visible even if my focus is in the editor
Never mind, the little toolbar in the editor is coming from the editor command , not our terminal one.
Code change:
} @command('git.clone') <del> async clone(url?: string, parentPath?: string): Promise<void> { await this.cloneRepository(url, parentPath); </del> <ins> async clone(url?: string, parentPath?: string, options?: { ref?: string }): Promise<void> { await this.cloneRepository(url, parentPath, options); </ins> } @command('git.cloneRecursive')

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. --vscode- a directory to clone your repo into cloned repo :bug: branch context is not preserved This impacts Continue Working On--branch context is preserved for Clone in Container and Create New Codespace. I propose adding a new optional query parameter to the uri handler here: and passing that to the command as an optional argument here Then after cloning here: and before opening the repo in a new window, we would perform the ref checkout:
will you create a test plan item/verification steps for this feature?
yes I will!
Code change:
) { } } <del> class CodeLensCache implements ICodeLensCache { </del> <ins> export class CodeLensCache implements ICodeLensCache { </ins> _serviceBrand: any;

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: master Ran into this issue while preparing Monaco release in vscode repo open monaco-editor test page switch monaco-editor-core source to not found error in Dev Console is registered through which is only read by workbench We can add the singleton services to standalone but a simple standalone service can also fix the problem <img width="576" alt="image" src="https://user-" let me know if you have time for a quick fix, if not I can push my change to branch first to unblock publishing.
FYI is also made to ensure work at this moment. Unluckily our intermediate typescript files for tree shaking don't apply to yet. The commit will be cherry-picked to master later.
There is no need for , the default implementation is good enough and just needs to be brought into the editor land.
please review
can you clarify the steps for this? I'm not sure where the monaco-editor test page is
I can take this one
Code change:
break; } <del> const itemKindFilter = SuggestModel._createItemKindFilter(this._editor); </del> <ins> const { itemKind: itemKindFilter, showDeprecated } = SuggestModel._createSuggestFilter(this._editor); </ins> const wordDistance = WordDistance.create(this._editorWorkerService, this._editor); const completions = provideSuggestionItems( model, this._editor.getPosition(), <del> new CompletionOptions(snippetSortOrder, itemKindFilter, onlyFrom), </del> <ins> new CompletionOptions(snippetSortOrder, itemKindFilter, onlyFrom, showDeprecated), </ins> suggestCtx, this._requestToken.token );

Related discussion:
text: I'd like a setting to optionally prevent deprecated things from showing up in intellisense suggestions. For example, I'd like a way to prevent from being suggested here, so that I don't use it despite a non-deprecated version being available. ! My linter can catch it, but it'd be even nicer never to see the deprecated option. There are several documentation systems that use the tag: JSDoc: TSDoc: JavaDoc: Yard (for Ruby): Other systems use different, similar tags. I'm not sure if this is an issue for the VSCode core, or for something language-specific.
Sorry if this is a duplicate or is already possible. There are enough issues here and questions/answers on Stack Overflow that it's hard to be confident. This issue is related:
Not showing deprecated suggestions can be implemented by individual language extensions today (not striking out but tracks that). Adding just to see this is something we want better VS Code api support for in some way Otherwise, we can track this as a feature request for js/s
I'd say this is a dupe of and it would be us adding some API flag and then allows users to configure how the suggest UX is handling that flag
/duplicate of
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues . See also our guidelines. Happy Coding!
Okay, that makes sense. What does "js/s" mean?
is it possible to add a setting like , so I can disable it to prevent deprecated from showing up in suggestions list?
Hey any update on that?
Verify that the setting exists and that it filters deprecated elements from IntelliSense
Code change:
const pendingCommentText = (this._pendingNewCommentCache[uniqueOwner] && this._pendingNewCommentCache[uniqueOwner][thread.threadId]) ?? continueOnCommentText; const pendingEdits = this._pendingEditsCache[uniqueOwner] && this._pendingEditsCache[uniqueOwner][thread.threadId]; <del> const isThreadTemplateOrEmpty = (thread.isTemplate || (!thread.comments || (thread.comments.length === 0))); const shouldReveal = thread.canReply && isThreadTemplateOrEmpty && (!thread.editorId || (thread.editorId === editorId)); </del> <ins> const shouldReveal = thread.canReply && thread.isTemplate && (!thread.comments || (thread.comments.length === 0)) && (!thread.editorId || (thread.editorId === editorId)); </ins> await this.displayCommentThread(uniqueOwner, thread, shouldReveal, pendingCommentText, pendingEdits); this._commentInfos.filter(info => info.uniqueOwner === uniqueOwner)[0].threads.push(thread); this.tryUpdateReservedSpace();

Related discussion:
text: !
Caused by I caused when I fixed an issue when there are multiple text editors open with the same uri with comments. When I tried to fix I made it so when extensions call and pass in for the comments, we always expand the reply editor, resulting in the bad behavior above. I took a quick look, and it seems very common for extensions to pass in for the comments and then immediately set them.
To verify: Check out PR with comments that you left Reload to make sure there's not state left over from when you left the comments Open the file with the comments and click on the comment icon in the comment bar to expand a comment that you left Verify that the reply input button is collapsed and isn't a big empty rectangle.
Works great -verified.
<!-- UNABLETOLOCATECOMMITMESSAGE repo --Issue marked as unreleased but unable to locate closing commit in repo history. If this was closed in a separate repo you can add the label directly, or comment .
<!-- UNABLETOLOCATECOMMITMESSAGE --Issue marked as unreleased but unable to locate closing commit in issue timeline. You can manually reference a commit by commenting , or directly add the label if you know this has already been releaased
Code change:
"editor.background": "#1f1f1f", "editor.findMatchBackground": "#9e6a03", "editor.foreground": "#ffffffd3", <del> "editorCursor.foreground": "#0078d4", </del> "editorGroup.border": "#ffffff17", "editorGroupHeader.tabsBackground": "#181818", "editorGroupHeader.tabsBorder": "#ffffff15",

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.0-insider OS Version: Linux Hello, IMHO, the block cursor could use a different background. Default Dark+ Experimental (v2): ! ! Default Dark+: ! ! Default Dark+ Experimental (v2): with some cursor background color. For ex: ! ! ! ! Edit (one more option) (with color set to 's value, giving inverted cursor effect) ! ! Thanks
Code change:
return false; } <del> let rootPath = root.fsPath + (root.fsPath.endsWith(sep) ? '' : sep); let resourceFsPath = resource.fsPath; </del> <ins> let resourceFsPath = normalize(resource.fsPath); let rootPath = normalize(root.fsPath + (root.fsPath.endsWith(sep) ? '' : sep)); </ins> if (isUNC(root.fsPath) && isUNC(resource.fsPath)) { rootPath = rootPath.toLowerCase();

Related discussion:
text: An information disclosure vulnerability exists in VS Code 1.71 and earlier versions. If an attacker is able to run arbitrary scripts inside of a webview (either created by extension or by core VS Code), the attacker could bypass the local resource roots check to read arbitrary files on the user's system The fix is available starting with VS Code 1.71.1. The mitigates this attack by performing input validation on the URL pointing to the repository to be cloned. Only use webviews from extensions that follow proper security measures to block script injection Do not disable VS Code's default security measures in the built-in markdown preview The patch for this can be found at An advisory for this can be found at MSRC details for this can be found at
Hi, just curious about this: The description of the vulnerability ends mid-sentence. I see the same phrasing on the GHSA advisory as well: Can it be revised to be clearer what is the nature of the vulnerability? (And of course: Thanks for finding and fixing it, and for making these advisories! Transparency and security are appreciated!)
Updated
Should the references to 1.71 in fact be 1.72?
Code change:
// Ask for confirmation const { confirmed } = await dialogService.confirm({ <del> message: localize('confirmClearMessage', "Do you want to clear the history of recently used commands?"), </del> <ins> message: localize('confirmClearMessage', "Do you want to clear the previous session command history?"), </ins> detail: localize('confirmClearDetail', "This action is irreversible!"), primaryButton: localize({ key: 'clearButtonLabel', comment: ['&& denotes a mnemonic'] }, "&&Clear"), type: 'warning'

Related discussion:
text: Testing Linux some commands in your terminal 1 Terminal Clear Command History 1 Terminal run recent commands the commands are still there, nothing got cleared !
This is by design as clearing history only clears the previous session commands. We don't discard the current session as they're all in the active terminal marked by decorations. It does however clear the active terminal's current session history from the previous session history (which hides by default as they would duplicate the content).
I find this very counterintuitive... As no other clear command in VS Code behaves that way.
I cleared recently opened and the active windows still show up, this is essentially the same thing the terminal history is doing: !
On macOS, i run , and when i run again, i can see all the commands, including those from the previous session. <img width="802" alt="Screen Shot 2022-02-24 at 11 07 24 AM" src="https://user-"
I agree that it's a little confusing. Perhaps we should say instead?
I now get the clear command history and a clear previous session command history command. Neither command seems to be clearing the command history. I'm on Windows with pwsh. !
the change you made was to the quickaccess code, this is nothing to do with the terminal so we need to revert that
can you help with verification steps for this one. Since I do not see the "Clear Command History" in quick pick. Does this only appear on Linux?
the title of the command is
thanks. After running that commend I still see the recent commands. So the command history is not cleared. Is this expected?
I still see previous session history commands given to the terminal after running the command.
is the group called or is it or something similar? Only the first is expected to be cleared. This worked fine for me just now.