jiebi/CodeConvo huggingface dataset:
Code change:
// Don't dispose editor when instance is torn down on shutdown to avoid extra work and so // the editor/tabs don't disappear <del> this._lifecycleService.onWillShutdown(() => { </del> <ins> this._lifecycleService.onWillShutdown((e: WillShutdownEvent) => { </ins> this._isShuttingDown = true; dispose(disposeListeners); <ins> // Don't touch processes if the shutdown was a result of reload as they will be reattached const shouldPersistTerminals = this._configurationService.getValue<boolean>(TerminalSettingId.EnablePersistentSessions) && e.reason === ShutdownReason.RELOAD; if (shouldPersistTerminals) { instance.detachProcessAndDispose(TerminalExitReason.Shutdown); } else { instance.dispose(TerminalExitReason.Shutdown); } </ins> }); }

Related discussion:
text: Type: <bBug</bis enabled. Ensure is set to , or (any option that will restore the last open window after quiting and re-opening VSCode). a terminal in the editor area, e.g. using the command "Terminal: Create New Terminal in Editor Area". Type something into the terminal e.g. . VSCode via "Developer: Reload Window". Note that the terminal tab in the editor area is still there (restored) after the window is reloaded. This is the expected behavior. VSCode then reopen the application. Note that the terminal tab is not present (is not restored) when the window is restored (and since there is no terminal tab, there is also nowhere to restore the session to ) . This is unexpected behavior as previously this terminal tab would be restored into the editor area, with its session history, even after quitting and reopening VSCode. Another terminal persistence bug on 1.74.0, also related to killing terminals: VS Code version: Code 1.74.0 (, 2022-12-05T16:37:54.581Z) OS version: Darwin arm64 22.2.0 Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryExtensions (16)</summaryExtensionVersion ------ vscode-neovim0.0.94 calva2.0.321 file-browser0.2.11 portal0.35.0 viml0.1.7 prettier-vscode9.10.3 vscode-htmlhint1.0.4 vscode-sshfs1.25.0 ssh-config-syntax-highlighter0.0.4 sqltools0.26.0 sqltools-driver-pg0.4.0 errorlens3.6.0 learn-vim0.0.28 vspacecode0.10.10 whichkey0.11.3 markdown-all-in-one3.5.0 </details<!-- generated by issue reporter --
I cannot reproduce that in Insider's https://user-
have you typed in the terminal before reloading? if not, that's by design
Pardon me I was unclear in the original writeup. The problem occurs in step 4 and is now reflected in edits above. Thank you! Regarding the direct question: yes, I have typed in the terminal before reloading.
Code change:
// Don't dispose editor when instance is torn down on shutdown to avoid extra work and so // the editor/tabs don't disappear <del> this._lifecycleService.onWillShutdown(() => { </del> <ins> this._lifecycleService.onWillShutdown((e: WillShutdownEvent) => { </ins> this._isShuttingDown = true; dispose(disposeListeners); <ins> // Don't touch processes if the shutdown was a result of reload as they will be reattached const shouldPersistTerminals = this._configurationService.getValue<boolean>(TerminalSettingId.EnablePersistentSessions) && e.reason === ShutdownReason.RELOAD; if (shouldPersistTerminals) { instance.detachProcessAndDispose(TerminalExitReason.Shutdown); } else { instance.dispose(TerminalExitReason.Shutdown); } </ins> }); }

Related discussion:
text: /duplicate
Reviving editor-area terminals was working great in 1.73.x. This was marked as a duplicate of a feature request. Is it not a regression?
Created a PR with a possible fix
VSCode v1.74.2 occurs the same problem, does the fix takes effect or I need to config some settings?
The fix will be available in 1.75 release or you can try it in insiders
Code change:
return c; } clientSnippetSupport = getClientCapability('textDocument.completion.completionItem.snippetSupport', false); dynamicFormatterRegistration = getClientCapability('textDocument.rangeFormatting.dynamicRegistration', false) && (typeof initializationOptions.provideFormatter !== 'boolean'); foldingRangeLimitDefault = getClientCapability('textDocument.foldingRange.rangeLimit', Number.MAX_VALUE); hierarchicalDocumentSymbolSupport = getClientCapability('textDocument.documentSymbol.hierarchicalDocumentSymbolSupport', false); formatterMaxNumberOfEdits = initializationOptions.customCapabilities?.rangeFormatting?.editLimit || Number.MAX_VALUE; <del> const pullDiagnosticSupport = getClientCapability('textDocument.diagnostic', undefined); if (pullDiagnosticSupport === undefined) { </del> <ins> const supportsDiagnosticPull = getClientCapability('textDocument.diagnostic', undefined); if (supportsDiagnosticPull === undefined) { </ins> diagnosticsSupport = registerDiagnosticsPushSupport(documents, connection, runtime, validateTextDocument); } else { diagnosticsSupport = registerDiagnosticsPullSupport(documents, connection, runtime, validateTextDocument); } const capabilities: ServerCapabilities = { textDocumentSync: TextDocumentSyncKind.Incremental, completionProvider: clientSnippetSupport ? {

Related discussion:
text: LSP now support pull diagnostics. Adopt for [x] CSS [x] JSON [x] HTML
Code change:
import { ICodeEditor } from 'vs/editor/browser/editorBrowser'; import { NullLogService } from 'vs/platform/log/common/log'; import { Handler } from 'vs/editor/common/editorCommon'; <del> import { timeout } from 'vs/base/common/async'; </del> suite('SnippetController2', function () {

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:
import { ITerminalInstance, IXtermTerminal } from 'vs/workbench/contrib/terminal/browser/terminal'; import { TerminalCommandId } from 'vs/workbench/contrib/terminal/common/terminal'; import type { Terminal } from '@xterm/xterm'; <ins> import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; </ins> export const enum ClassName { Active = 'active',

Related discussion:
text: Type: <bFeature Request</bCC Please consider auto-activiating accessible view in terminal when user hit enter key. In most cases, screen reader users want to open accessible view after executing command in terminal. Thus, pressing Enter key can do: the current command to terminal. Accessible View immediately. Rather than having this as the default mode, we could consider adding this as a custom user setting. VS Code version: Code - Insiders 1.85.0-insider (, 2023-11-02T09:02:24.464Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
This makes sense. let us know if you have any thoughts.
I imagine this mode can boost user productivity because VSCode now sends user typing in Accessible View directly to the active terminal. If this mode is , users will experience more seamless round trip between terminal input and accessible view without having to press Alt+F2 and ESC.
To verify, enable . Run a command in the terminal. The accessible view should open.
Code change:
res = path.substr(0, pos); } res += encodeTable[code]; <del> } else { if (res !== undefined) { res += path[pos]; } </del> <ins> } else if (res !== undefined) { res += path[pos]; </ins> } } return res !== undefined ? res : path;

Related discussion:
text: Issue Type: <bBug</bdeveloper tools themes Everything appears to work as normal, but the console gets flooded with errors. VS Code version: Code - Insiders 1.36.0-insider (, 2019-06-14T10:36:51.530Z) OS version: Darwin x64 18.6.0 <details<summarySystem Info</summary </details<details<summaryExtensions (13)</summaryExtensionVersion ------ vscode-eslint1.9.0 gitlens9.8.2 vsc-material-theme2.9.0 remote-containers0.61.0 remote-ssh-edit-nightly2019.6. remote-ssh-explorer-nightly2019.6. remote-ssh-nightly2019.6. vscode-typescript-tslint-plugin1.1.0 debugger-for-chrome4.11.3 vscode-docker0.6.2 material-icon-theme3.8.0 polacode0.3.2 vscode-sort-json1.13.0 </details<!-- generated by issue reporter --
I can't repo this. Which developer tools and theme are you talking about specifically?
I tried repoing this again and it appears that this error is related to installing a new theme. Here are some better repo steps: developer tools themes (no errors) a theme themes (errors even if it is one of the themes shipped with VS code) The errors go away after a reload, but installing a theme does not tell me a reload is required.
Ok, with the extensions view open, I sometimes see Does not cause seem to cause any actual problems
I get that as well sometimes, but do you not get the webview must be attached to the DOM error as well?
I can reproduce it. Steps: on any extension to load it's Readme in an editor that editor theme (this triggers the webview error) step 1 (this triggers the guestInstanceId error)
Code change:
default: 'openOnFirstSessionStart', description: nls.localize('openDebug', "Controls whether debug view should be open on debugging session start.") }, <ins> 'debug.enableAllHovers': { type: 'boolean', description: nls.localize({ comment: ['This is the description for a setting'], key: 'enableAllHovers' }, "Controls if the non debug hovers should be enabled while debugging. If true the hover providers will be called to provide a hover. Regular hovers will not be shown even if this setting is true."), default: false }, </ins> 'launch': { type: 'object', description: nls.localize({ comment: ['This is the description for a setting'], key: 'launch' }, "Global debug launch configuration. Should be used as an alternative to 'launch.json' that is shared across workspaces"),

Related discussion:
text: To be verified with: : : set the new config options start debugging The hover provider should be invoked.
Code change:
class TestTerminalContributionService implements ITerminalContributionService { _serviceBrand: undefined; terminalProfiles: readonly IExtensionTerminalProfile[] = []; <del> quickFixes: ITerminalCommandSelector[] = []; </del> <ins> quickFixes: Promise<ITerminalCommandSelector[]> = new Promise((r) => { r([]); }); </ins> setProfiles(profiles: IExtensionTerminalProfile[]): void { this.terminalProfiles = profiles; }

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:
this._isChangingDecorations = false; this._shouldFocus = false; this._colorPicker = null; <ins> this._preferBelow = this._editor.getOption(EditorOption.hover).below; </ins> this._hoverOperation = new HoverOperation( this._computer,

Related discussion:
text: Issue Type: <bFeature Request</bI want the message could display under the variables it refers to. Because the message box blocks the code over the current line. Thank you. VS Code version: Code 1.36.1 (, 2019-07-08T22:59:35.033Z) OS version: Windows_NT x64 10.0. <!-- generated by issue reporter --
Can we just change the default to or does this require a setting?
Kind of feel like this is out of scope, but I don't think this should be assigned to me since it's regarding monaco.
Actually I was wrong - it is determined by : I verified if I swap the order then the hovers appear below instead of above (where there's space). I'll make a PR.
Done! Before: <img width="734" alt="Screenshot 2021-06-30 at 08 45 06" src="https://user-"Change the setting: <img width="921" alt="Screenshot 2021-06-30 at 08 45 14" src="https://user-"After: <img width="777" alt="Screenshot 2021-06-30 at 08 45 22" src="https://user-"
Let's continue tracking in
Code change:
MoveToEditorInstance = 'workbench.action.terminal.moveToEditorInstance', MoveToTerminalPanel = 'workbench.action.terminal.moveToTerminalPanel', SetDimensions = 'workbench.action.terminal.setDimensions', <del> ClearCommandHistory = 'workbench.action.terminal.clearCommandHistory', </del> <ins> ClearPreviousSessionHistory = 'workbench.action.terminal.clearPreviousSessionHistory', </ins> WriteDataToTerminal = 'workbench.action.terminal.writeDataToTerminal', ShowTextureAtlas = 'workbench.action.terminal.showTextureAtlas', ShowTerminalAccessibilityHelp = 'workbench.action.terminal.showAccessibilityHelp',

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.
Code change:
background-color: var(--vscode-inlineChat-regionHighlight); } <del> .monaco-workbench .inline-chat-slash-command { </del> <ins> .monaco-workbench .interactive-session .interactive-input-and-execute-toolbar .monaco-editor .inline-chat-slash-command { </ins> background-color: var(--vscode-chat-slashCommandBackground); <del> color: var(--vscode-chat-slashCommandForeground); </del> <ins> color: var(--vscode-chat-slashCommandForeground); /* Overrides the foreground color rule in chat.css */ </ins> border-radius: 4px; padding: 1px; }

Related discussion:
text: Testing ! !
doesn't reproduce in the panel chat
I somehow suffer from this change which explicitly targets some monaco tokens...
This isn't nice but there's actually no other way to override the foreground color of an editor- because typically you have syntax highlighting. We do this for all the other "input box"-style editors. I think I opened a feature request when I did this. We should align this rule with your rule for coloring the decoration so that it can override it properly.
labeling so it gets verified
Thanks
in the latest insider's, still seeing this ! !
There is two separate issues with different steps. There is a difference between rendering of slash command and normal prompt text. the only useful/visible information in the original issue description is slash commands (please use words and not images to describe issues!). For verification you have not used slash commands but normal prompt text which is a different case. Please file a separate issue, use words/steps and don't rely on screen captures with just white on white text
Steps to reproduce/verify use HC light and dark theme open inline chat and type a slash command, e.d make sure the command is readable when selecting its text
Code change:
break; } } <del> characterBounds.push(new DOMRect(parentBounds.left + contentLeft + left, top, width, lineHeight)); </del> <ins> characterBounds.push(new DOMRect(parentBounds.left + contentLeft + left - editorScrollLeft, top, width, lineHeight)); </ins> } this._editContext.updateCharacterBounds(e.rangeStart, characterBounds); }

Related discussion:
text: Version: 1.94.0-insider Commit: Date: 2024-09-23T05:12:01.964Z Electron: 30.5.0 ElectronBuildId: Chromium: 124.0.6367.243 20.16.0 V8: 12.4.254.20-electron.0 OS: Darwin arm64 22.6.0 Steps to Reproduce: a very long line. Google IME for Japanese. at the last of the long line. position of the IME widget is not optimal. ! With , it is worse. !
Hi yes thanks a lot for opening this valuable issue. This is happening because we use the model ranges instead of the view ranges in the control bounds, selection bounds and character bounds positioning. The following PR fixes this:
I try the OSS version from the repository. The issue with is fixed. However, I still see the issue with Version: 1.94.0 Commit: Date: Unknown Electron: 30.5.1 ElectronBuildId: undefined Chromium: 124.0.6367.243 20.16.0 V8: 12.4.254.20-electron.0 OS: Darwin arm64 22.6.0 a very long line. Google IME for Japanese. at the last of the long line. position of the IME widget is not optimal. !
Oh I see thanks for letting me know that is curious. I will reopen the issue and have a look.
After investigating the issue, I believe this happens because I didn't remove the editor scroll left position from the bounds set for the selection and character bounds. The following PR should fix this.
Code change:
readonly shortStats?: boolean; readonly author?: string; readonly refNames?: string[]; <ins> readonly maxParents?: number; </ins> } export interface CommitOptions {

Related discussion:
text: a folder/workspace in VS Code Insiders a git repository in the folder a file, make changes to it, and create multiple commits Expected: commits should appear in the history graph Actual: no commits are being shown in the history graph
this only works when there are multiple commits. I.e. if we has just one commit in the repo, then history isn't displayed. Else works as expected.
Thanks! I have filed to handle the single commit scenario
Code change:
override updateOptions(options: IWorkbenchDataTreeOptionsUpdate = {}): void { super.updateOptions(options); <del> if (options.overrideStyles) { </del> <ins> if (options.overrideStyles !== undefined) { </ins> this.internals.updateStyleOverrides(options.overrideStyles); }

Related discussion:
text: I opened the Settings editor, hovered over a setting, and noticed a new grey line appear to the left of the settings. This issue occurs with the default light and dark themes. !
I found that when calling , if we don't pass in the style override anymore, it will be reset to default I put this fix for notebook but I wonder if it's unexpected
Thanks for figuring that out. We shouldn't update options that are not set, that a regression. I fixed that with and updated your code to back what it was. Is different, it's about the indent guides which were disabled previously by not providing any colors. With my change we complete your colors with the default colors, which IMO is the right thing to do. is a simple fix. But I think we should not use the colors for that but the already existing option. I'm working on a follow up PR, but that needs to be reviewed by who is out today.
Code change:
await this._stageChanges(textEditor, [changes[index]]); <del> const firstStagedLine = changes[index].modifiedStartLineNumber - 1; </del> <ins> const firstStagedLine = changes[index].modifiedStartLineNumber; </ins> textEditor.selections = [new Selection(firstStagedLine, 0, firstStagedLine, 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 <!-- 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.71.0 (user setup) OS Version: Windows_NT x64 10.0. Git Version: 2.30.2 (Windows) Steps to Reproduce: a new directory a new Git repository a new file and append some text on the first lines this file to the staging the line with text An OS native dialog box error pops up with the title of this issue as text. In the console output for Git: I have had this problem for a long time, 2 years I would say. I thought someone would have reported it but it seems not.
I'm having a similar issue on macOS 12.6 (21G115). If you have deleted lines at the top of a file and click the little arrow to undo the change, the error pops up. Notably, it still completes the undo. <img width="396" alt="image" src="https://user-"
apologies for not getting back to you on this. I used the repro steps above but I was unable to reproduce the problem with the latest VS Code Insiders (1.75) release. Could you please do me a favour and see if you are still able to reproduce the issue? If so, could you please share a recording using so that I can further investigate the issue? Thanks!
Issue is still present in the latest insider release on macOS. !