jiebi/CodeConvo huggingface dataset:
Code change:
// Complete when wait marker file is deleted whenDeleted(waitMarkerFilePath).done(c, c); <ins> }).then(() => { // Make sure to delete the tmp stdin file if we have any if (stdinFilePath) { fs.unlinkSync(stdinFilePath); } </ins> }); }

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:
import { coalesce } from 'vs/base/common/arrays'; import Severity from 'vs/base/common/severity'; import { ThemeIcon as ThemeIconUtils } from 'vs/platform/theme/common/themeService'; <del> import { checkProposedApiEnabled } from 'vs/workbench/services/extensions/common/extensions'; </del> export type Item = string | QuickPickItem;

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. --We already have this feature in Core: where you can return where . Truth be told, this already works in API today though it's not officially a part of the API today (so it could change at any moment). For example, I can do: <img width="738" alt="image" src="https://user-"with it goes from: to it goes from: to
ref
Created a TPI so moving this to April for Finalization.
Code change:
} private onDidChangePresentation(): void { <del> this._pickedColorNode.textContent = this.model.presentation ? this.model.presentation.label : ''; this._pickedColorNode.prepend($('.codicon.codicon-color-mode')); </del> <ins> this._pickedColorPresentation.textContent = this.model.presentation ? this.model.presentation.label : ''; </ins> } }

Related discussion:
text: When the content hover contains a color picker and it is resized too small, the text and the color picker box overflow. Perhaps the text should disappear when there is not enough space for the text.
At least the text does not wrap to the next line anymore, but imho the text should remain visible for as long as possible and could possibly also have text-overflow: ellipses? <img width="153" alt="image" src=""
Hi thanks for your comment. The following PR which was merged yesterday should set a minimum width on the content hover when a color picker is embedded and resolve the issue. The fix should appear in today's insiders with commit number
Indeed, thanks!
Code change:
// other flows that work well. supportsGitHubEnterpriseServer: false, supportsHostedGitHubEnterprise: true, <del> supportsRemoteExtensionHost: true, </del> <ins> // Opening a port on the remote side can't be open in the browser on // the client side so this flow won't work in remote extension hosts supportsRemoteExtensionHost: false, </ins> // Web worker can't open a port to listen for the redirect supportsWebWorkerExtensionHost: false, // exchanging a code for a token requires a client secret

Related discussion:
text: Summary: The sign-in link for Github in VSCode running through serve-web rotates ports in the 54xxx range, breaking any pre-set port forwarding for users connecting via SSH. This occurs regardless of any port option set with --port (taken from my comment in ) Does this issue occur when all extensions are disabled?: Yes VS Code Version: Insiders 1.82.0 OS Version: Mac OS 13.3 Steps to Reproduce: to the device hosting code via SSH, with local port forwarding for port 8000 enabled the remote device, launch serve-web with a browser window and navigate to the URL given by serve-web on settings sync, showing a github sign-in URL. Note the port is different than the default, requiring you to reconnect and add a new forwarded port Expected behavior: Setting the port with --port should (a) also determine the port used for sign-in, or (b) be a separate option so that SSH port forwarding does not require updating SSH config and reconnecting each time you need to sign in
is the github sign-in URL in step 4 coming from you?
This flow shouldn't actually happen in the remote case and instead the user should get the device code flow. Fixed this by disabling the local server flow in
Verification: turn on Settings Sync using GitHub when you go through the auth flow, you should get the Device Code Flow first
Code change:
async focusNextPage(browserEvent?: UIEvent, filter?: (element: T) => boolean): Promise<void> { let lastPageIndex = this.view.indexAt(this.view.getScrollTop() + this.view.renderHeight); lastPageIndex = lastPageIndex === 0 ? 0 : lastPageIndex - 1; <del> const lastPageElement = this.view.element(lastPageIndex); </del> const currentlyFocusedElementIndex = this.getFocus()[0]; <del> const currentlyFocusedElement = this.view.element(currentlyFocusedElementIndex); if (currentlyFocusedElement !== lastPageElement && lastPageIndex > currentlyFocusedElementIndex) { </del> <ins> if (currentlyFocusedElementIndex !== lastPageIndex && (currentlyFocusedElementIndex === undefined || lastPageIndex > currentlyFocusedElementIndex)) { </ins> const lastGoodPageIndex = this.findPreviousIndex(lastPageIndex, false, filter); <del> if (lastGoodPageIndex > -1 && currentlyFocusedElement !== this.view.element(lastGoodPageIndex)) { </del> <ins> if (lastGoodPageIndex > -1 && currentlyFocusedElementIndex !== lastGoodPageIndex) { </ins> this.setFocus([lastGoodPageIndex], browserEvent); } else { this.setFocus([lastPageIndex], 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:
private _pattern = ''; get pattern(): string { return this._pattern; } <ins> private previousPattern = ''; </ins> private _mode: TreeFindMode; get mode(): TreeFindMode { return this._mode; }

Related discussion:
text: Testing When find box is not visible and I just type but there are multiple results, then maybe allow me via keybindings (F3?) to go to next/prev result?
You mean using the type navigation feature? I think this would be too implicit. I don't know of any other native widget doing something like this.
I think the editor has a way to navigate in find results even without showing find. i think in that mode it only puts the search toggles up in a little overlay.
The editor opens up the widget once again, when pressing <kbdF3</kbd. Yeah we can do that.
I think the tree does the same, I had tried and it showed the input box, but it was empty though.
Yeah. Renamed this to remember the input across usages, which is what the editor does.
Code change:
private readonly _onSocketClose = new BufferedEmitter<SocketCloseEvent>(); readonly onSocketClose: Event<SocketCloseEvent> = this._onSocketClose.event; <del> private readonly _onSocketTimeout = new BufferedEmitter<void>(); readonly onSocketTimeout: Event<void> = this._onSocketTimeout.event; </del> <ins> private readonly _onSocketTimeout = new BufferedEmitter<SocketTimeoutEvent>(); readonly onSocketTimeout: Event<SocketTimeoutEvent> = this._onSocketTimeout.event; </ins> public get unacknowledgedCount(): number { return this._outgoingMsgId - this._outgoingAckId;

Related discussion:
text: I've had an SSH window open in the background and noticed that it keeps going through reconnection. Looking at the logs, it looks like vscode is often triggering reconnection, even though nothing strange is going on with my network, as far as I know. Noticed this at home and also the office network. This is the log from vscode. The SSH log doesn't show anything unusual before the resolver is invoked again. Has anything changed here lately?
Sorry this issue fell through the cracks. Are you still running into this?
Yes
Do you perhaps have a log with tracing enabled? The reason in the original log appears to be timeout. That is triggered here -- So the conditions are: a message was written to the socket 20 seconds ago and the server side didn't acknowledge it (and) no data was received from the server within the past 20 seconds (and) no previous timeout event was fired within the past 20 seconds (this just avoid sending many timeout events) (and) the renderer process appears responsive (Just speculating) I think we have fixed something in the terminal land and we now no longer send any data in an idle window. Could it be that your window becomes idle and the connection is dropped by SSH? (I believe due to some terminal heartbeat mechanism there was always data being written every 5 seconds, but now that is no longer happening).
Well, now I can't repro it.
I've more logging via . Please keep an eye out. In case you hit this again, the logging will have more data.
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Finally got it
It seems like the log message you touch didn't show up there. But, it does show up in an earlier reconnection in this window (before I enabled trace logging). So I'll just share the full logs This shows a window that was mostly idle with 2 reconnections, the second one had logging at the trace level enabled
Here's my interpretation: the management connection timed out at due to our own timeout logic. We wrote one message and that message didn't get acknowledged within 20s by the server. As an observation, the connection didn't receive any bytes from the server within 320s (5 minutes).
Code change:
private readonly _onSocketClose = new BufferedEmitter<SocketCloseEvent>(); readonly onSocketClose: Event<SocketCloseEvent> = this._onSocketClose.event; <del> private readonly _onSocketTimeout = new BufferedEmitter<void>(); readonly onSocketTimeout: Event<void> = this._onSocketTimeout.event; </del> <ins> private readonly _onSocketTimeout = new BufferedEmitter<SocketTimeoutEvent>(); readonly onSocketTimeout: Event<SocketTimeoutEvent> = this._onSocketTimeout.event; </ins> public get unacknowledgedCount(): number { return this._outgoingMsgId - this._outgoingAckId;

Related discussion:
text: this resulted in the core invoking on the SSH extension and the SSH extension replied with a new port i.e. instead of the previous . the extension host connection immediately closed at with code , indicating that perhaps the previous tunnel at was killed as part of invoking . Precisely 20 minutes later, at , both management and extension host connections receive a event from Chromium. I can't quite explain the first timeout, why would the server not acknowledge a message within 20 seconds? But the timing of the second disconnection seems to indicate to me that after 20 min of idleness, the underlying connection is closed. Anyone could be closing it: either on the client side by Chromium or the OS, either on the server side by nodejs or the OS, either by the SSH tunnel timing out. For the second disconnection I think we might need to do something to tackle . For a long time the terminal was doing a heartbeat mechanism which resulted in data being sent over the wire (and that would not make the connection idle), but that was fixed via Right now, if you are really idle in a window, the underlying connection will be idle too and I think the OS or someone closes it as idle after 20 minutes.
My best guess is some other weird optimization where network requests don't even get delivered when an app is in the background. I've noticed this in windows that are not focused
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Code change:
this.table.domNode.ariaLabel = label; } <del> setMarkerSelection(marker?: Marker): void { </del> <ins> setMarkerSelection(selection?: Marker[], focus?: Marker[]): void { </ins> if (this.isVisible()) { <del> if (marker) { const index = this.findMarkerIndex(marker); if (index !== -1) { this.table.setFocus([index]); this.table.setSelection([index]); </del> <ins> if (selection && selection.length > 0) { this.table.setSelection(selection.map(m => this.findMarkerIndex(m))); if (focus && focus.length > 0) { this.table.setFocus(focus.map(f => this.findMarkerIndex(f))); } else { this.table.setFocus([this.findMarkerIndex(selection[0])]); </ins> } } else if (this.getSelection().length === 0 && this.getVisibleItemCount() > 0) { this.table.setFocus([0]);

Related discussion:
text: Testing Not sure if this lack of functionality blocks anything truly useful, but at least in the treeview, you can multi-select problems and copy them to the clipboard. In the table view you can't.
This also has the side effect of losing a multi-select that you may have had in the treeview.
what was the thinking for enabling multi-select in the problems treeview? Was there a particular scenario or this is what the default behaviour is for a treeview? If there is a real scenario, than we should enable multi-select in the table as well.
You can copy multiple problems is the primary use case.
that makes sense. Thanks!
Code change:
// TODO@ulugbekna: could this be simply run in `afterRender`? setTimeout(() => { this._input.domNode.focus(); <del> this._input.domNode.select(); </del> <ins> this._input.domNode.setSelectionRange( parseInt(this._input!.domNode.getAttribute('selectionStart')!), parseInt(this._input!.domNode.getAttribute('selectionEnd')!) ); </ins> }, 100); }

Related discussion:
text: Select a portion of a variable name Press F2 Previously, the rename widget would open with the same substring highlighted. It's helpful to quickly rename one subword in a variable name, for example. Now, the full contents of the input in the rename widget are highlighted initially. I don't know who owns this but it looks like you touched it recently
<!-- 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:
"@vscode/iconv-lite-umd": "0.7.0", "@vscode/tree-sitter-wasm": "^0.0.4", "@vscode/vscode-languagedetection": "1.0.21", <del> "@xterm/addon-clipboard": "0.2.0-beta.39", "@xterm/addon-image": "0.9.0-beta.56", "@xterm/addon-search": "0.16.0-beta.56", "@xterm/addon-serialize": "0.14.0-beta.56", "@xterm/addon-unicode11": "0.9.0-beta.56", "@xterm/addon-webgl": "0.19.0-beta.56", "@xterm/xterm": "5.6.0-beta.56", </del> <ins> "@xterm/addon-clipboard": "^0.2.0-beta.47", "@xterm/addon-image": "^0.9.0-beta.64", "@xterm/addon-search": "^0.16.0-beta.64", "@xterm/addon-serialize": "^0.14.0-beta.64", "@xterm/addon-unicode11": "^0.9.0-beta.64", "@xterm/addon-webgl": "^0.19.0-beta.64", "@xterm/xterm": "^5.6.0-beta.64", </ins> "jschardet": "3.1.3", "tas-client-umd": "0.2.0", "vscode-oniguruma": "1.7.0",

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. After updating to VS Code 1.92, I noticed several scroll-related issues with the integrated terminal: exiting a full screen CLI app ( or ), sometimes scroll up or down doesn't work anymore until I press cmd+c - at which point I am teleported back to the start of the cli log. See the below video: start scroll works (though way too sensitive - see issue 2) press scroll up down no longer works press as soon as I try to scroll again, I am teleported to the top of the cli log output (though, at least scroll works after that)Note, while the above triggers the issue, sometimes the issue also occurs even without that (at one point I just run and this bug was triggered) full-screen CLI apps (, , ), the scroll sensitivity is way higher than when scrolling in non-full-screen apps. This scroll sensitivity is uncomfortably high, way higher than it was before, and remains high even if I set to a very low value like 0.1. scrolling through full-screen CLI app ( or ), sometimes the terminal will not let me scroll up. If I try to scroll up, I am "teleported" back to previous position. As soon as I scroll down, I can't scroll back up to the previous text. <!-- 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. --Relevant information: VS Code Version: 1.92 OS Version: macOS 14.5 Issues are reproducible in ZSH.
Code change:
"@vscode/iconv-lite-umd": "0.7.0", "@vscode/tree-sitter-wasm": "^0.0.4", "@vscode/vscode-languagedetection": "1.0.21", <del> "@xterm/addon-clipboard": "0.2.0-beta.39", "@xterm/addon-image": "0.9.0-beta.56", "@xterm/addon-search": "0.16.0-beta.56", "@xterm/addon-serialize": "0.14.0-beta.56", "@xterm/addon-unicode11": "0.9.0-beta.56", "@xterm/addon-webgl": "0.19.0-beta.56", "@xterm/xterm": "5.6.0-beta.56", </del> <ins> "@xterm/addon-clipboard": "^0.2.0-beta.47", "@xterm/addon-image": "^0.9.0-beta.64", "@xterm/addon-search": "^0.16.0-beta.64", "@xterm/addon-serialize": "^0.14.0-beta.64", "@xterm/addon-unicode11": "^0.9.0-beta.64", "@xterm/addon-webgl": "^0.19.0-beta.64", "@xterm/xterm": "^5.6.0-beta.64", </ins> "jschardet": "3.1.3", "tas-client-umd": "0.2.0", "vscode-oniguruma": "1.7.0",

Related discussion:
text: I was also able to trigger issue 1 in BASH In ZSH, I am using oh-my-zsh and powerlevel19k, BUT I was able to reproduce the issues even after I temporary disabled oh-my-zsh and powerlevel19k in my Issues are reproducible even if I start VS Code with empty user dir and empty extensions dir. A few relevant settings: is off. Enabling it does not make things better N/A as I am not holding the key - I am just scrolling using the touchpad is off. Enabling it did not make things better I am sorry if some of the above reproduction steps a bit vague - some of these don't happen each time so it's hard to see what triggered it. But these all started happening as soon as VS Code got updated to 1.92. I will keep updating this issue if I have more details. <details<summarySystem info</summaryGeneral: System info: System Information | -- | -- CPUs | Apple M1 Pro (10 x 2400) GPU Status | 2dcanvas: enabled canvasooprasterization: enabledon directrenderingdisplaycompositor: disabledoffok gpucompositing: enabled multiplerasterthreads: enabledon opengl: enabledon rasterization: enabled rawdraw: disabledoffok skiagraphite: disabledoff videodecode: enabled videoencode: enabled webgl: enabled webgl2: enabled webgpu: enabled webnn: disabled_off Load (avg) | 2, 2, 3 Memory (System) | 32.00GB (6.06GB free) Process Argv | /Users/mak13180/site/esri/arcgis-web-components --crash-reporter-id -0746-4857-a17b- Screen Reader | no VM | 0% Enabled extensions (BUT, issues are reproducible with all extensions disabled): Extension Version -- -- vite 0.2.5 shell-syntax 1.0.5 vscode-tailwindcss 0.12.5 vscode-eslint 3.0.10 apc-extension 0.4.1 gitlens 15.2.3 vscode-html-css 2.0.10 prettier-vscode 10.4.0 lintlens 7.5.0 copilot 1.219.0 copilot-chat 0.18.1 vscode-github-actions 0.26.
Code change:
"@vscode/iconv-lite-umd": "0.7.0", "@vscode/tree-sitter-wasm": "^0.0.4", "@vscode/vscode-languagedetection": "1.0.21", <del> "@xterm/addon-clipboard": "0.2.0-beta.39", "@xterm/addon-image": "0.9.0-beta.56", "@xterm/addon-search": "0.16.0-beta.56", "@xterm/addon-serialize": "0.14.0-beta.56", "@xterm/addon-unicode11": "0.9.0-beta.56", "@xterm/addon-webgl": "0.19.0-beta.56", "@xterm/xterm": "5.6.0-beta.56", </del> <ins> "@xterm/addon-clipboard": "^0.2.0-beta.47", "@xterm/addon-image": "^0.9.0-beta.64", "@xterm/addon-search": "^0.16.0-beta.64", "@xterm/addon-serialize": "^0.14.0-beta.64", "@xterm/addon-unicode11": "^0.9.0-beta.64", "@xterm/addon-webgl": "^0.19.0-beta.64", "@xterm/xterm": "^5.6.0-beta.64", </ins> "jschardet": "3.1.3", "tas-client-umd": "0.2.0", "vscode-oniguruma": "1.7.0",

Related discussion:
text: 3 vscode-pull-request-github 0.92.0 gc-excelviewer 4.2.59 todo-tree 0.0.226 search-node-modules 1.3.0 nodejs-repl 0.5.15 rainbow-csv 3.12.0 remote-ssh 0.112.0 remote-ssh-edit 0.86.0 remote-explorer 0.4.3 vscode-css-peek 4.4.1 vscode-yaml 1.15.0 code-spell-checker 3.0.1 vscode-stylelint 1.4.0 vscode-mdx 1.8.9 vscodeintellicode 1.3.1 explorer 1.0.6 vim 1.27.3 pretty-ts-errors 0.6.0 markdown-all-in-one 3.6.2 A/B experiment info: My (BUT, issues are also reproducible when VS Code is started with empty user dir): The log when VS Code is started as : </details
Upstream PR fixing it