jiebi/CodeConvo huggingface dataset:
Code change:
resolved "https://registry.yarnpkg.com/escape-string-regexp/-/escape-string-regexp-2.0.0.tgz#a30304e99daa32e23b2fd20f51babd07cffca344" integrity sha512-UpzcLCXolUWcNu5HtVMHYdXJjArjsF9C0aNnquZYY4uW/Vu0miy5YoWvbV345HauVvcAUnpRuhMMcqTcGOY2+w== <ins> eslint-plugin-header@3.1.1: version "3.1.1" resolved "https://registry.yarnpkg.com/eslint-plugin-header/-/eslint-plugin-header-3.1.1.tgz#6ce512432d57675265fac47292b50d1eff11acd6" integrity sha512-9vlKxuJ4qf793CmeeSrZUvVClw6amtpghq3CuWcB5cUNnWHQhgcqy5eF8oVKFk1G3Y/CbchGfEaw3wiIJaNmVg== </ins> eslint-plugin-jsdoc@^19.1.0: version "19.1.0" resolved "https://registry.yarnpkg.com/eslint-plugin-jsdoc/-/eslint-plugin-jsdoc-19.1.0.tgz#fcc17f0378fdd6ee1c847a79b7211745cb05d014"

Related discussion:
text: Currently, we have to add this copyright header manually to every new file: /
Copyright (c) Microsoft Corporation. All rights reserved. Licensed under the MIT License. See in the project root for license information. *
-------------/ An ES Lint rule that has an auto fix would be really nice. What are your thoughts ! (using )
I like. The closest that we have today is this snippet
Let's do it!
Code change:
return Promise.all(bps.map(bp => debugService.removeBreakpoints(bp.getId()))); } if (debugService.getConfigurationManager().canSetBreakpointsIn(editor.getModel())) { <del> return debugService.addBreakpoints(modelUri, [{ lineNumber: position.lineNumber }]); </del> <ins> return debugService.addBreakpoints(modelUri, [{ lineNumber: position.lineNumber }], 'debugEditorActions.toggleBreakpointAction'); </ins> } return Promise.resolve(null);

Related discussion:
text: When going over our telemetry for debug actions we have the ability to track usage counts of debug actions triggered from keyboard shortcuts and commands, as they execute commands which we emit telemetry for, but we don't seem to have telemetry in place for breakpoints set in the gutter (click or context menu). This is unfortunate as my hypothesis is that the majority of breakpoints are set this way. Ask Add ability to track breakpoint toggles (add/remove/change) from Gutter click Add ability to track breakpoint toggles from gutter context menu
would you like to contribute a PR for this? It shuold be fairly simple and you already have the nice code pointers.
I'd be happy too, but we should land on an agreement on how to implement it. What's the best approach? 1) Add telemetry directly to the gutter actions 2) Re-wire the gutter actions to execute a command instead?
for the best approach let's first see what you want to get exactly? total amount of all breakpoints set (including the gutter) grained events for breakpoint setting based on the way the user initated that aciton In case of 1 we should just add a telemetry ping in the  since everyone should go through there In case of 2 depends on how fine grained you want it, if for every place then we should add an argument or something like that in the addBreakpoints method and then also report that to telemetry.
I'd like us to be able to contribute a source/initiator to given breakpoint, so we can get an UI usage distributions, etc.
I suggest the following Add a third argument In the implementation of that method use the telemetry service to report the appropriate event with the context. And you should nicely get all the errors of all the callers of , simply pass different string context for each caller and you shuold be good to go. Let me know if you have any questions
Cool, I'l see what I can get cooking!
Removing my assignment for this. feel free to assign me back if you do not have time to tackle this and if we need this for August
hey, would you still like this? If yes I can also look into it in October
I'd still like to do this to get my hands dirty.
cool, unasigning myself and let's leave it for October
Verified by code review, adding verified label
Code change:
# Visual Studio Code - Open Source <del> [VS Code](http://code.visualstudio.com) is a new choice of tool that combines the simplicity of a code editor with what developers need for their core edit-build-debug cycle. Code provides comprehensive editing and debugging support, an extensibility model, and lightweight integration with existing tools. </del> <ins> [VS Code](http://code.visualstudio.com) is a new type of tool that combines the simplicity of a code editor with what developers need for their core edit-build-debug cycle. Code provides comprehensive editing and debugging support, an extensibility model, and lightweight integration with existing tools. </ins> <img width="550" alt="vscodereadme" align="middle"  src="https://cloud.githubusercontent.com/assets/1487073/11243985/98562110-8e0b-11e5-9922-29a0b4884eab.png">

Related discussion:
text: Issue Type: <bBug</bGitHub reported a security vulnerability related to the NPM package in my VS Code extension's . <img width="765" alt="Screen Shot 2019-06-18 at 5 49 45 PM" src="https://user-"In my VS Code extension's , I've a dependency for : When I run to see what packages are using , I see this: <img width="156" alt="Screen Shot 2019-06-18 at 5 49 23 PM" src="https://user-"And I see this reflected in my : VS Code version: Code 1.35.1 (, 2019-06-12T14:29:22.216Z) OS version: Darwin x64 18.6.0 <details<summarySystem Info</summary </details<details<summaryExtensions (15)</summaryExtensionVersion ------ vscode-css-formatter1.0.1 npm-intellisense1.3.0 path-intellisense1.4.2 bracket-pair-colorizer1.0.61 vscode-eslint1.9.0 gitlens9.8.2 vscode-npm-script0.3.7 auto-rename-tag0.1.0 beautify1.5.0 ibm-streams0.5.0 vscode-duplicate1.2.1 java0.46.0 change-case1.0.0 JavaScriptSnippets1.7.2 ReactSnippets2.3.0 </details<!-- generated by issue reporter --
Seems NPM org is taken by someone :( I'm now forking mocha to update to fix security alert Wondering what I should do :one: Publish it under :two: Make depends on octref/mocha on GitHub :three: We should create a NPM org for these kind of packages What do you think?
can't we just update to mocha 5 or 6 in the vscode module?
will talk to you in chat
Ah, I thought Mocha 5/6 would have breaking changes so we can't really upgrade easily. Turns out Mocha 5 only had : Drop IE9/10 support. It shouldn't affect us. Meanwhile if someone really needs Mocha 4. He can use and manually depends on it. Will upgrade to Mocha 5.
Thanks
Code change:
import { IChatReplyFollowup, IChatService, ISlashCommand, InteractiveSessionVoteDirection } from 'vs/workbench/contrib/chat/common/chatService'; import { IChatRequestViewModel, IChatResponseViewModel, IChatWelcomeMessageViewModel, isRequestVM, isResponseVM, isWelcomeVM } from 'vs/workbench/contrib/chat/common/chatViewModel'; import { IWordCountResult, getNWords } from 'vs/workbench/contrib/chat/common/chatWordCounter'; <ins> import { IAccessibilityService } from 'vs/platform/accessibility/common/accessibility'; </ins> import { AccessibilityVerbositySettingId } from 'vs/workbench/contrib/accessibility/browser/accessibilityContribution'; const $ = dom.$;

Related discussion:
text: We should not translate the PHP parser error messages, but we should localize the strings that appear in the Code UI. !
Code change:
await profiler.writeProfile(profileMain, `${filenamePrefix}-main.cpuprofile${suffix}`); await profiler.writeProfile(profileRenderer, `${filenamePrefix}-renderer.cpuprofile${suffix}`); await profiler.writeProfile(profileExtHost, `${filenamePrefix}-exthost.cpuprofile${suffix}`); }); }

Related discussion:
text: This is very useful when working with the commandline, and to pass the result directly into the editor. It's especially useful for getting a file out of git's history, eg: FWIW, this works in Sublime.
+1
Here is my workaround (I'm on OSX so might need to adjust accordingly): create ~/bin/codestdin: Then run: Now git log, git show, git diff pipe correctly into vscode
Similar to approach, I've this to my bash profile to wrap the command... definitely not flawless, but it works for my use cases (so far). e.g.
For you have to modify the function a bit and use , because is a BUILTIN in and will return the function itself: What does not work is something like
Hello, For using the redirect, does this express the intent of getting of copy of the file contents assigned to an anonymous file buffer? Would that be similar to for intents sake? I wonder if are the only thing to care for that scenario? Thank you. Good day.
hello yes this should be equivalent as as I know.
Can we get some priority for this issue? It's been open since 2016 (that's 552 days!) and it's a bit ridiculous that VSCode still doesn't provide this extremely rudimentary shell interoperability.
+1
Pushed a change to feed the contents of stdin to a file and have it open in VS Code ( is implied when doing so): ! This currently works by or not, which is a bit brittle. If someone spawns VS Code without terminal emulation we might wrongly assume that data is coming in via stdin and open a tmp file. If it turns out that there are too many regressions, I might have to add a startup argument (, ) to explicitly enable this. If someone has a better idea how to detect if data is flowing in via stdin let me know.
This is great to see! Thanks so much! Is Atom's implementation the same?
as far as I know, Atom does not support this.
huh, I really thought it did, but local tests (and ) suggest not. Anyway, thanks again!
Hello, would you be kind enough to update your OP to note that Atom did and does not as of writing actively support this (probably just taking it out).
Code change:
await profiler.writeProfile(profileMain, `${filenamePrefix}-main.cpuprofile${suffix}`); await profiler.writeProfile(profileRenderer, `${filenamePrefix}-renderer.cpuprofile${suffix}`); await profiler.writeProfile(profileExtHost, `${filenamePrefix}-exthost.cpuprofile${suffix}`); }); }

Related discussion:
text: There is the PR for them, but it is nice to have the proper perspective that VSCode is in the forefront of this kind of feature. Its no harm to stay, just misleading. Thank you. Good day.
done
Thanks for the feature, very nice. Just my 2 cents on feedback, the implied seems unnecessary. EG: when I pipe to TextMate it gives me my prompt back. There might be other reasons though for having the wait that I'm not thinking about though. Regardless, cheers and thanks for the work!
the calling process is waiting because it is not clear how long data is being sent to . It could be that the editor is already opened but data is still flowing. A workaround on your side would probably to send the command to the background by appending "" at the end?
Hrm, wasn't aware that was even possible. I feel like most commands I pipe complete then output is sent to the editor.
A terminal can have a specific encoding set which my solution did not yet account for. I pushed a change to try a little bit of terminal encoding guessing but I think the solution is not ideal. If someone has a better idea ( ?), let me know: Linux/macOS: use the output of running as encoding Windows: use by default any OS: if you specify an environment variable it will always win over the guessing This will not help if you change the encoding of the terminal ad-hoc as that does not seem to cause any configuration change that the command would detect. On Windows I see the  command but the output of that command seems to be intertwined with human readable text and not just the encoding. If someone has a better idea for Windows, please speak up.
Code change:
} if (outputLineHeight || fontSize || outputFontSize) { <del> configuration.outputLineHeight = this._computeOutputLineHeight(); </del> <ins> const lineHeight = this.configurationService.getValue<number>(NotebookSetting.outputLineHeight); configuration.outputLineHeight = this._computeOutputLineHeight(lineHeight, configuration.outputFontSize); </ins> } if (outputWordWrap) {

Related discussion:
text: Testing There are "" "notebook.outputLineHeight" "" "notebook.outputFontFamily" "notebook.outputFontSize" Ideally these would be all namespaced or prefixed .
This affects how they show up in the settings editor UI, btw: <img width="919" alt="image" src="https://user-"
Code change:
<del> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ declare module 'vscode' { // https://github.com/microsoft/vscode/issues/127473 /** * The state of a comment thread. */ export enum CommentThreadState { Unresolved = 0, Resolved = 1 } export interface CommentThread { /** * The optional state of a comment thread, which may affect how the comment is displayed. */ state?: CommentThreadState; } } </del>

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:
<del> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ declare module 'vscode' { // https://github.com/microsoft/vscode/issues/127473 /** * The state of a comment thread. */ export enum CommentThreadState { Unresolved = 0, Resolved = 1 } export interface CommentThread { /** * The optional state of a comment thread, which may affect how the comment is displayed. */ state?: CommentThreadState; } } </del>

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:
<del> /*--------------------------------------------------------------------------------------------- *  Copyright (c) Microsoft Corporation. All rights reserved. *  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ declare module 'vscode' { // https://github.com/microsoft/vscode/issues/127473 /** * The state of a comment thread. */ export enum CommentThreadState { Unresolved = 0, Resolved = 1 } export interface CommentThread { /** * The optional state of a comment thread, which may affect how the comment is displayed. */ state?: CommentThreadState; } } </del>

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:
this.stateModel.setRuntimeValue(LayoutStateKeys.SIDEBAR_HIDDEN, true); } } <ins> // Side bar is hidden and a new window is opened with activity bar not visible (not default) else if (isNewWindow && activityBarNotDefault) { // Open side bar if there is a view container to restore const viewContainerToRestore = this.storageService.get(SidebarPart.activeViewletSettingsKey, StorageScope.WORKSPACE, this.viewDescriptorService.getDefaultViewContainer(ViewContainerLocation.Sidebar)?.id); if (viewContainerToRestore) { this.state.initialization.views.containerToRestore.sideBar = viewContainerToRestore; this.stateModel.setRuntimeValue(LayoutStateKeys.SIDEBAR_HIDDEN, false); } } </ins> // Panel View Container To Restore if (this.isVisible(Parts.PANEL_PART)) {

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. --I found that once the [Activity Bar Position] is set to [Top], i can't find the activity bar at the top anymore, when i click [File-New Window] to open a new window. Therefore, i suggest display the activity bar by default when opening a new window.
<img width="1068" alt="" src=""As shown in the picture, the new window does not display the activity bar.
I like this idea, I will look into it.