jiebi/CodeConvo huggingface dataset:
Code change:
import { ParsedArgs } from 'vs/platform/environment/common/environment'; import product from 'vs/platform/node/product'; import pkg from 'vs/platform/node/package'; import * as paths from 'path'; import * as os from 'os'; <ins> import * as fs from 'fs'; </ins> import { whenDeleted } from 'vs/base/node/pfs'; <del> import { writeFileAndFlushSync } from 'vs/base/node/extfs'; </del> import { findFreePort } from 'vs/base/node/ports'; function shouldSpawnCliProcess(argv: ParsedArgs): boolean {

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:
import { ParsedArgs } from 'vs/platform/environment/common/environment'; import product from 'vs/platform/node/product'; import pkg from 'vs/platform/node/package'; import * as paths from 'path'; import * as os from 'os'; <ins> import * as fs from 'fs'; </ins> import { whenDeleted } from 'vs/base/node/pfs'; <del> import { writeFileAndFlushSync } from 'vs/base/node/extfs'; </del> import { findFreePort } from 'vs/base/node/ports'; function shouldSpawnCliProcess(argv: ParsedArgs): boolean {

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:
this.menuDisposables = []; <ins> addDisposableListener(menuElement, EventType.KEY_DOWN, (e) => { const event = new StandardKeyboardEvent(e); // Stop tab navigation of menus if (event.equals(KeyCode.Tab)) { EventHelper.stop(e, true); } }); </ins> if (options.enableMnemonics) { this.menuDisposables.push(addDisposableListener(menuElement, EventType.KEY_DOWN, (e) => { const key = e.key.toLocaleLowerCase();

Related discussion:
text: Issue Type: <bBug</bthe refactoring window over any element with many available refactoring options (e.g.: a widget in Flutter) tab selection won't move BUT if you hit enter it will choose an option other than the highlighted one VS Code version: Code 1.33.1 (, 2019-04-11T08:27:14.102Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </detailsExtensions disabled <!-- generated by issue reporter --
Assigning because this only happens when using custom title bars. Repo Windows with custom title bar enabled the ts file: code actions and press tab once or twice, then enter The second or third code action ends up being applied even though the visible selection never changes
Code change:
firstPageIndex = this.view.indexAfter(scrollTop - 1); } <del> const firstPageElement = this.view.element(firstPageIndex); </del> const currentlyFocusedElementIndex = this.getFocus()[0]; <del> const currentlyFocusedElement = this.view.element(currentlyFocusedElementIndex); if (currentlyFocusedElement !== firstPageElement && currentlyFocusedElementIndex >= firstPageIndex) { </del> <ins> if (currentlyFocusedElementIndex !== firstPageIndex && (currentlyFocusedElementIndex === undefined || currentlyFocusedElementIndex >= firstPageIndex)) { </ins> const firstGoodPageIndex = this.findNextIndex(firstPageIndex, false, filter); <del> if (firstGoodPageIndex > -1 && currentlyFocusedElement !== this.view.element(firstGoodPageIndex)) { </del> <ins> if (firstGoodPageIndex > -1 && currentlyFocusedElementIndex !== firstGoodPageIndex) { </ins> this.setFocus([firstGoodPageIndex], browserEvent); } else { this.setFocus([firstPageIndex], browserEvent);

Related discussion:
text: Open Select the top cell and page down a few times Focus hits a cell that is longer than the viewport, which is maybe important, then the next page down moves to a higher cell
When a list item is larger than the viewport, and it's also the only element in the viewport, pressing page down will reveal to the previous element, this is because we did a here (the catch is, the last page element is also the first page element)
Code change:
"continueEditSession": [ { "command": "github.openOnVscodeDev", <del> "when": "github.hasGitHubRepo" </del> <ins> "when": "github.hasGitHubRepo", "qualifiedName": "Continue Working in VS Code for the Web" </ins> } ], "menus": {

Related discussion:
text: Testing If I run "Continue working on...," I get many development environments to target, but I only see one Continue Working in command for the codespace option.
Verified from the remote repositories options. Looks like 1 and 2 (local folder and local container) still need to add entries to be consistent. <img width="355" alt="image" src="https://user-"
who should add the built-in command?
Code change:
readonly _serviceBrand: undefined; readonly terminalProfiles: ReadonlyArray<IExtensionTerminalProfile>; <del> readonly quickFixes: Array<ITerminalCommandSelector>; </del> <ins> readonly quickFixes: Promise<Array<ITerminalCommandSelector>>; </ins> } export const ITerminalContributionService = createDecorator<ITerminalContributionService>('terminalContributionsService');

Related discussion:
text: Running out of sources I see this:
This means that the contribution isn't getting evaluated before is called. Not too familiar with how / when is handled, but we call when the is created
I think perhaps moving that to the top of the constructor (before registering the command handlers) will fix this
This happens on window open
and the quick fix does work for that extension !
Seeing this in error telemetry for Insiders from 12/23:
This is the 6th error by machines in telemetry https://vscode-
I cannot reproduce this in Insider's. did you notice this after doing anything in particular?
I got this error when using remote dev container <details<summaryWindow</summary</details
Fixed in
Actually still found it in my devtools today:
I can't reproduce, but I can simulate the race by adding to 's promise in
HI, im having the same problem here 2023-02-16 17:10:14.453 [error] Error: No registered selector for ID: ms- at R.registerQuickFixProvider (vscode-file://vscode-) at r.$registerQuickFixProvider (vscode-file://vscode-) at m.N (vscode-file://vscode-) at m.M (vscode-file://vscode-) at m.H (vscode-file://vscode-) at m.G (vscode-file://vscode-) at vscode-file://vscode- at g.invoke (vscode-file://vscode-) at n.deliver (vscode-file://vscode-) at a.fire (vscode-file://vscode-) at r.fire (vscode-file://vscode-) at Z.onmessage (vscode-file://vscode-) I got vs code 1.71.1 running on W11 21H2 How i am supposed to fix this, or it's not a problem and vs code is working normally? Thank you!
Update your VS code version, where this is fixed
Sorry, i typed incorrectly mi vs code version. It is the latest one 1.75.1, i reinstalled it today.
I can still reproduce in latest stabel 1.75.1 https://user-
Code change:
private _state?: vscode.CommentThreadState; get state(): vscode.CommentThreadState { <del> checkProposedApiEnabled(this.extensionDescription, 'commentsResolvedState'); </del> return this._state!; } set state(newState: vscode.CommentThreadState) { <del> checkProposedApiEnabled(this.extensionDescription, 'commentsResolvedState'); </del> this._state = newState; this.modifications.state = newState; this._onDidUpdateCommentThread.fire();

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:
private _state?: vscode.CommentThreadState; get state(): vscode.CommentThreadState { <del> checkProposedApiEnabled(this.extensionDescription, 'commentsResolvedState'); </del> return this._state!; } set state(newState: vscode.CommentThreadState) { <del> checkProposedApiEnabled(this.extensionDescription, 'commentsResolvedState'); </del> this._state = newState; this.modifications.state = newState; this._onDidUpdateCommentThread.fire();

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:
private _state?: vscode.CommentThreadState; get state(): vscode.CommentThreadState { <del> checkProposedApiEnabled(this.extensionDescription, 'commentsResolvedState'); </del> return this._state!; } set state(newState: vscode.CommentThreadState) { <del> checkProposedApiEnabled(this.extensionDescription, 'commentsResolvedState'); </del> this._state = newState; this.modifications.state = newState; this._onDidUpdateCommentThread.fire();

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:
import { Range } from 'vs/editor/common/core/range'; import { registerAction2 } from 'vs/platform/actions/common/actions'; import { assertIsDefined } from 'vs/base/common/types'; <ins> import { ActionBar } from 'vs/base/browser/ui/actionbar/actionbar'; import { toAction } from 'vs/base/common/actions'; import { ThemeIcon } from 'vs/base/common/themables'; </ins> const EDITOR_DICTATION_IN_PROGRESS = new RawContextKey<boolean>('editorDictation.inProgress', false); const VOICE_CATEGORY = localize2('voiceCategory', "Voice");

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:
if (restoreFocus) { this.explorerViewer.setFocus(modelElement); } <ins> //Expand the element again if (isExpanded) { this.explorerViewer.expand(modelElement); } </ins> }, errors.onUnexpectedError); }); }

Related discussion:
text: Issue Type: Bug folder ! VS Code version: Code - Insiders 1.21.0-insider (, 2018-02-21T09:22:14.399Z) OS version: Windows_NT x64 10.0. Reproduces without extensions <!-- generated by issue reporter --
Code pointer
does it mean that this is the expected behavior?
I m on it.
it is always debatable if something is a feature-request or a bug. I guess this is more of a bug, but I took the artistic freedom and assigned feature-request.
it does not seem to restore the full expansion state, only the first level is that true?
yes, only the first level. could improve the PR and try to restore more.
Yes, i can do that.
great, tree should have api to get the exapnsion state. And once the pr is ready just ping me on it.
Should i make a new method to return all the expanded children as array on treeModel?
Is this ready for verification?
ben already verified and can add a verified label. There are some limitation which will tackle in a pr for next milestone
Code change:
private _hoverClicked: boolean; private _isHoverEnabled!: boolean; private _isHoverSticky!: boolean; <ins> private _hidingDelay!: number; </ins> private _hoverActivatedByColorDecoratorClick: boolean = false; <ins> private _mouseWasOverWidget: boolean = false; private _hideWidgetsTimeout: NodeJS.Timeout | undefined; </ins> static get(editor: ICodeEditor): ModesHoverController | null { return editor.getContribution<ModesHoverController>(ModesHoverController.ID);

Related discussion:
text: Currently the hover disappear as soon as the mouse leaves the content hover. Sometimes the user leaves briefly the content hover. The ask is to wait until some times (ex. 500 ms) has passed before measuring whether the mouse is within the hover or not, then make the hover disappear or not.
This would be quite helpful in resizing the hover (because it's easy to go out of the hover when aiming for the angle to hover with a mouse). But I would think 500 ms is too much for that use case
Code change:
*  Licensed under the MIT License. See License.txt in the project root for license information. *--------------------------------------------------------------------------------------------*/ <del> import { ChildProcess, ChildProcessWithoutNullStreams, spawn, SpawnOptions } from 'child_process'; </del> <ins> import { ChildProcess, spawn, SpawnOptions, StdioOptions } from 'child_process'; </ins> import { chmodSync, existsSync, readFileSync, statSync, truncateSync, unlinkSync } from 'fs'; import { homedir, release, tmpdir } from 'os'; import type { ProfilingSession, Target } from 'v8-inspect-profiler';

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.
Code change:
import { NotebookDiffViewModel } from './notebookDiffViewModel.js'; import { INotebookService } from '../../common/notebookService.js'; import { DiffEditorHeightCalculatorService, IDiffEditorHeightCalculatorService } from './editorHeightCalculator.js'; <ins> import { IEditorService } from '../../../../services/editor/common/editorService.js'; </ins> const $ = DOM.$;

Related discussion:
text: Testing For this issue I used a notebook with one cell that contains the following code: <details<summaryfile </summarydata= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) data= {} df = pd.DataFram(data) </details- Stage this code Make a change Open the diff view in the SCM pane Open the metadata view Type into the metadata view The metadata view closes before anything can be typed Is this expected?