jiebi/CodeConvo huggingface dataset:
Change:
if (!neverMeasureRenderTime && this._configHelper.config.gpuAcceleration !== 'off') { this._measureRenderTime(); } <del> XtermTerminal._suggestedRendererType = 'canvas'; this._disposeOfWebglRenderer(); this._enableCanvasRenderer(); </del> <ins> this._disableWebglForThisSession(); </ins> } } <ins> private _disableWebglForThisSession() { XtermTerminal._suggestedRendererType = 'canvas'; this._disposeOfWebglRenderer(); this._enableCanvasRenderer(); } </ins> private async _enableCanvasRenderer(): Promise<void> { if (!this.raw.element || this._canvasAddon) { return;

Discussion:
Type: <bBug</bOpen terminal. Start typing. Note the noticeable delay in the text rendering on screen even though the cursor advances. In fact some timess the text never renders. Makes the terminal pretty unusable. VS Code version: Code - Insiders 1.82.0-insider (, 2023-08-10T05:33:20.243Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (19)</summaryExtensionVersion ------ togglehs0.1.2 vscode-eslint2.4.2 githistory0.6.20 gitlens2023.8.1005 dotnet-test-explorer0.7.8 copilot1.101.325 copilot-chat0.7. vscode-mojom0.1.4 mojom-language0.0.1 vscode-clangd0.1.24 csharp2.0.328 vscode-dotnet-runtime1.6.0 python2023.15. vscode-pylance2023.8.21 remote-wsl0.81.0 cpptools1.17.1 powershell2023.6.0 vscode-jest5.2.3 clang-format1.9.0 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
does changing help?
Yes. It apparently was set to auto previously. If it turn it to "off" the issue goes away.
repro's for me with set to or . does not repro for or gif: !
I can't reproduce this unfortunately
I still have a consistent repro if you want me to try anything or collect diagnostics.
Findings from looking at it together: It repro'd in Code - OSS It did not repro in xterm demo It did not repro in Code - OSS with symlinked webgl addon It repro'd after running scripts/update-xterm
I'm going to manually look through all the code that went in around rendering ~1-2 weeks ago to see if I can spot something.
Maybe it's related to Chromium.
Upstream bug filed at , thanks to
<!-- 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!
Verified on Linux
verified on windows
Change:
const blobSegment = repository?.state.HEAD?.name ? encodeURIComponentExceptSlashes(repository.state.HEAD?.name) : repository?.state.HEAD?.commit; const filepathSegment = encodeURIComponentExceptSlashes(item.resourceUri.path.substring(repository?.rootUri.path.length)); const rangeSegment = getRangeSegment(item); <del> return vscode.Uri.parse(`${this.getVscodeDevHost()}/${repo.owner}/${repo.repo}/blob/${blobSegment}${filepathSegment}${rangeSegment}${rangeSegment}`); </del> <ins> return vscode.Uri.parse(`${this.getVscodeDevHost()}/${repo.owner}/${repo.repo}/blob/${blobSegment}${filepathSegment}${rangeSegment}`); </ins> }

Discussion:
Testing My extension's provider is not receiving the within the passed to its I think this's caused by this -

Testing takes a but doesn't respect the selector's . I created an extension which uses Share Provider API, but its share contribution wasn't being invoked. It seems the language isn't being passed - see 3rd arg being an empty string .
I observe the same, using: registers the share provider, however as soon as I add a language, this is no longer the case
Change:
import {IMessageService} from 'vs/platform/message/common/message'; import {IKeybindingService} from 'vs/platform/keybinding/common/keybindingService'; <del> import {remote} from 'electron'; </del> <ins> import {remote, webFrame} from 'electron'; </ins> export class ContextMenuService implements IContextMenuService {

Discussion:
I can confirm this happens for me as well. I am using Mac OS X. The operating system's display scaling is off (i.e. 1:1). I have been experimenting and it seems as though the bug is that the right click menu is displayed according to the cursor position, but this calculation is not adjusted to take into account zoom. The reason I say this is because if I right click near the top left of the editor, the cursor is quite close to the top left of the menu. But if I right click near the bottom right of the editor, the cursor is much further away from the top left of the menu. The misalignment is proportional to the distance from the top left of the editor.
Change:
import { Event } from 'vs/base/common/event'; import { localize } from 'vs/nls'; import { Registry } from 'vs/platform/registry/common/platform'; <del> import { editorErrorForeground, editorWarningForeground } from 'vs/editor/common/view/editorColorRegistry'; </del> <ins> import { listErrorForeground, listWarningForeground } from 'vs/platform/theme/common/colorRegistry'; </ins> import { IConfigurationService } from 'vs/platform/configuration/common/configuration'; import { IConfigurationRegistry, Extensions as ConfigurationExtensions } from 'vs/platform/configuration/common/configurationRegistry'; import { LifecyclePhase } from 'vs/platform/lifecycle/common/lifecycle';

Discussion:
The new error highlight in the explorer window is great, but for some reason the colours are all black for me. I've tried different themes, but it doesn't make any difference: !
Ah - I've figured it out. It's using the colour from 'editorError.foreground' from 'workbench.colorCustomizations'. I can see the logic in doing this, but I have the foreground colour set to black to hide the squigglies and use the border colour instead to show a double underline, which makes the stand out more. The theme has different colours for the editor area and the explorer area, so is it sensible to use the same colours? Maybe there should be a separate setting?
It's especially bad when you have transparent editor warnings and errors.
didn't you tweak the colors in the last endgame? is this still the same symbolic color?
This is what I've done:
Alright
I'd like to take this as my first issue. Can you point me where I can start?
Sure - here is the code that adds the decorations (using the squiggle colors): You can use the -function to define new colors, like here: I'd define two colors, for errors and for warnings.
Change:
# Handles git checkout|switch <ref> "^(?:checkout|switch).* (?<ref>S*)$" { <del> & { & { gitBranches $matches['ref'] $true gitRemoteUniqueBranches $matches['ref'] # Return only unique branches (to eliminate duplicates where the branch exists locally and on the remote) } | Select-Object -Unique | ConvertTo-VscodeCompletion -Type 'branch' gitTags $matches['ref'] | Select-Object -Unique | ConvertTo-VscodeCompletion -Type 'tag' } </del> <ins> gitBranches $matches['ref'] $true | ConvertTo-VscodeCompletion -Type 'branch' gitRemoteUniqueBranches $matches['ref'] | ConvertTo-VscodeCompletion -Type 'branch' gitTags $matches['ref'] | ConvertTo-VscodeCompletion -Type 'tag' </ins> } # Handles git worktree add <path> <ref>

Discussion:
Repro: /pwsh enabled vscode repo window, ideally one that has been long lived and has many local branches , the terminal freezes for several seconds !
Cause: ! ! Local branches: !
After deleting local branches: ! Seems to be no change after pruning and gc. I wonder what the overhead is building the completion items: !
Select-Object here adds a bit of overhead: ! VscodeCompletion a little: !
Maybe unique check should be done on client side, this is without : !
Change:
}); describe('Data Loss (stable -> insiders)', function () { <ins> // Double the timeout since these tests involve 2 startups this.timeout(4 * 60 * 1000); </ins> let insidersApp: Application | undefined = undefined; let stableApp: Application | undefined = undefined;

Discussion:
Callstack is similar to the one mentioned in but the issue remains First failure Second failure
The logs read very normal, we literally hit the 2min timeout. Since these tests do double the work (start VS Code 2 times), I will see if increasing the timeout helps.
Change:
when: CommentContextKeys.activeCursorHasCommentingRange }); <ins> registerAction2(class extends Action2 { constructor() { super({ id: CommentCommandId.FocusCommentOnCurrentLine, title: { value: nls.localize('comments.focusCommentOnCurrentLine', "Focus Comment on Current Line"), original: 'Focus Comment on Current Line' }, category: { value: nls.localize('commentsCategory', "Comments"), original: 'Comments' }, f1: true, precondition: CommentContextKeys.activeCursorHasComment, }); } override async run(accessor: ServicesAccessor, ...args: any[]): Promise<void> { const activeEditor = getActiveEditor(accessor); if (!activeEditor) { return; } const controller = CommentController.get(activeEditor); if (!controller) { return; } const position = activeEditor.getSelection(); const notificationService = accessor.get(INotificationService); let error = false; try { const commentAtLine = controller.getCommentsAtLine(position); if (commentAtLine.length === 0) { error = true; } else { await controller.revealCommentThread(commentAtLine[0].commentThread.threadId, undefined, false, CommentWidgetFocus.Widget); } } catch (e) { error = true; } if (error) { notificationService.error(nls.localize('comments.focusCommand.error', "The cursor must be on a line with a comment to focus the comment")); } } }); </ins> CommandsRegistry.registerCommand({ id: CommentCommandId.CollapseAll, handler: (accessor) => {

Discussion:
Type: <bFeature Request</bCC any file containing comment thread editor, move your cursor to any line having comment your cursor is on the line, press ctrl+K ctrl+I to see if the comment tolltip opens Screen reader users cannot open comment tooltip on the current line via ctrl+K ctrl+I ctrl+K ctrl+I needs to work for the comment tooltip just like other tooltips. VS Code version: Code - Insiders 1.93.0-insider (, 2024-08-20T08:04:15.567Z) OS version: Windows_NT x64 10.0. Modes: <!-- generated by issue reporter --
the comment widget is not a tooltip. We cannot reuse this keybinding to focus the comment widget because it's possible that line will have hover info. pls lmk if you disagree. I do wonder if we should have a focus closest comment widget command/keybinding.
Aw, I see. Please then consider adding a keybinding to focus the closest comment widget. Currently, alt+F9 and shift+alt+F9 go to the next and previous comment widget, but there is no action available to focus the comment on the current line.
It does make sense to have an "Expand and focus comment at current line" command.
The new command is "Focus Comment on Current Line" with no default keybinding.
To verify: Install an extension that provides comments GitHub Pull Requests can be used for this Sign in Open the Pull Requests view Open a file diff for a PR. If there aren't any comments in the file, add a comment on one of the changed lines and collapse the comment Put your cursor on a line in a file with a collapsed comment Open the command palette and run the command "Focus Comment on Current Line" Verify that the comment has focus
This should probably be to the comments and/or the editor accessibility help dialog for discoverability.
Change:
content.push(descriptionForCommand('notebook.cell.focusInOutput', localize('notebook.cell.focusInOutput', 'The Focus Output command ({0}) will set focus in the cell's output.'), localize('notebook.cell.focusInOutputNoKb', 'The Quit Edit command will set focus in the cell's output and is currently not triggerable by a keybinding.'), keybindingService)); <del> content.push(localize('notebook.cellNavigation', 'The up and down arrows will move focus between cells while focused on the outer cell container')); </del> <ins> content.push(descriptionForCommand('notebook.focusNextEditor', localize('notebook.focusNextEditor', 'The Focus Next Cell Editor command ({0}) will set focus in the next cell's editor.'), localize('notebook.focusNextEditorNoKb', 'The Focus Next Cell Editor command will set focus in the next cell's editor and is currently not triggerable by a keybinding.'), keybindingService)); content.push(descriptionForCommand('notebook.focusPreviousEditor', localize('notebook.focusPreviousEditor', 'The Focus Previous Cell Editor command ({0}) will set focus in the previous cell's editor.'), localize('notebook.focusPreviousEditorNoKb', 'The Focus Previous Cell Editor command will set focus in the previous cell's editor and is currently not triggerable by a keybinding.'), keybindingService)); content.push(localize('notebook.cellNavigation', 'The up and down arrows will also move focus between cells while focused on the outer cell container.')); </ins> content.push(descriptionForCommand('notebook.cell.executeAndFocusContainer', localize('notebook.cell.executeAndFocusContainer', 'The Execute Cell command ({0}) executes the cell that currently has focus.',), localize('notebook.cell.executeAndFocusContainerNoKb', 'The Execute Cell command executes the cell that currently has focus and is currently not triggerable by a keybinding.'), keybindingService));

Discussion:
suggested would be good for this
FYI, I have customized like below:
feel free to close if we already support this now.
We do not have a default keybinding that works along with the screen reader being enabled, though ctrl+pagedown/pageup are currently bound to next/previous editor, so I don't think we can use that one without breaking current workflows.
Maybe ctrl+alt+pagedown/pageup?
Change:
} const commandService = accessor.get(ICommandService); <del> await commandService.executeCommand('openInTerminal', provider.rootUri); </del> <ins> await commandService.executeCommand('openInIntegratedTerminal', provider.rootUri); </ins> }); MenuRegistry.appendMenuItem(MenuId.SCMSourceControl, {

Discussion:
<!-- 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/No <!-- 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.78.2 OS Version: Steps to Reproduce: VSCode version 1.78.2 to open a GIT repo the "source control repositories" right click on the repo name "open in terminal" cmd opens instead of VSCode integrated terminal Issue only introduced since VSCode 1.78.0, in 1.77.3 was opening in integrated terminal with no issues
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.78.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Issue appears in 1.78.2, starting from 1.78.0 it appears, last release not to have the issue was 1.77.3
the same issue
meanwhile waiting new release fix this. you can resolve by edit C:Users[username]AppDataLocalProgramsMicrosoft VS Coderesourcesappoutvsworkbench find then swap right after it. ! note: this will swap new function at
Possibly related on Stack Overflow:
Do you happen to know where this file is located on OSX?
it locate in /Applications/Visual Studio Code, right click Show package contents /Resources/app/out/vs/workbench Vào 14:54, Th 5, 25 thg 5, 2023 John viết:
Change:
import DOM = require('vs/base/browser/dom'); import lifecycle = require('vs/base/common/lifecycle'); <ins> import nls = require('vs/nls'); </ins> import platform = require('vs/base/common/platform'); import xterm = require('xterm'); import {Dimension} from 'vs/base/browser/builder'; <ins> import {IMessageService, Severity} from 'vs/platform/message/common/message'; </ins> import {ITerminalFont} from 'vs/workbench/parts/terminal/electron-browser/terminalConfigHelper'; import {ITerminalProcess, ITerminalService} from 'vs/workbench/parts/terminal/electron-browser/terminal'; import {IWorkspaceContextService} from 'vs/platform/workspace/common/workspace';

Discussion:
Steps to Reproduce: terminal as "faketerm" +`
On Linux (ElementaryOS) I get an error dialog with message 'The terminal process terminated with exit code: 1'. Setting as verified, although more details would be helpful.
Indeed that verifies it. Thanks.
Change:
const output: string[] = []; <del> output.push('CPU %tMem MBtProcess'); </del> <ins> output.push('CPU %tMem MBt   PIDtProcess'); </ins> formatProcessItem(mapPidToWindowTitle, output, rootProcess, 0);

Discussion:
should also print the PID of the processes. This makes it easier to debug or kill processes. It will also make it easier to profile processes, once we have integrated the profiling functionality we in the hackathon.
Change:
} } <del> private _toInteger(source: any, minimum: number, fallback: number): number { </del> <ins> private _toInteger(source: any, minimum: number, maximum: number, fallback: number): number { </ins> let r = parseInt(source, 10); if (isNaN(r)) { return fallback;

Discussion:
Testing Steps to Reproduce: the integrated terminal trying to set: , accidentally enter Bug ! Terminal contents start leaking outside of the panel. I also think we should set a maximum terminal font size just as we do for the minimum terminal font size
As a bit of polish the json schema could also include these ranges so a warning will appear in the settings panel.
Hi, I'd like to take this Issue up and make a PR. Thanks in advance PS: I'm new to Open Source and would like your support.
great! There's already a minimum value (), we just need to find a good maximum and add it there. Right now I'm thinking somewhere between 20 and 30 should be the default as that's getting into the ridiculously large territory. There are instructions for building the project here
Hi I've created a and would like your comments. Thanks for the great support.
Should it match the editor max font size? The editor has some max, not sure what it is, but I can now make the text much larger in the editor than the terminal.
Change:
const firstIndex = this.view.firstVisibleIndex; const elementHeight = this.view.elementHeight(viewIndex); <del> if (viewIndex <= firstIndex || elementHeight >= this.view.renderHeight) { this._revealInternal(viewIndex, true, CellRevealPosition.Top, firstLine); </del> <ins> if (viewIndex <= firstIndex || (!firstLine && elementHeight >= this.view.renderHeight)) { this._revealInternal(viewIndex, true, CellRevealPosition.Top); </ins> } else { this._revealInternal(viewIndex, true, CellRevealPosition.Bottom, firstLine); }

Discussion:
Testing Seems somewhat random... but doesn't seem to work between cell 1 and 2... but it works between cell 2 and 3. Cell 1: Cell 2: Cell 3:
I see the same behavior after resizing my window to a smaller size. In full screen mode, it works as expected
Change:
for (const [label, info] of history.entries) { // Only add previous session item if it's not in this session if (!commandMap.has(label) && info.shellType === this.shellType) { <del> previousSessionItems.push({ </del> <ins> previousSessionItems.unshift({ </ins> label, buttons: [removeFromCommandHistoryButton] });

Discussion:
Testing Session where commands got to the history: ! Later session: ! The command was run in two different locations and was last run. But in the previous session list it does not have it at the top. The order is not the same.
Previous session missing cwd is by design, we may choose to add it later when looking into autocomplete but for now it's meant to act more like an alternative to ctrl+r which doesn't track cwd on any shell. Additionally, if we tracked it we'd need to worry about keeping track of every cwd we track as only tracking the last cwd for a command feels a bit odd. Will look into the order.
To verifier: a shell integration enabled terminal , , echo commands should show up in the section, in order of most recently run a new window and the same terminal type as in echo commands should show up in the section, in order of most recently run
Step 7 fails for me. For step 5, I tried both opening a completely new window, and simply creating a new tab: !
I can repro but only if I open run recent very quickly, too quickly for the terminal to get classified as a pwsh which is a prerequisite to pulling in the history as it's segregated by shell type. Making as verified again, remove if I misunderstood.
Change:
this.runConfigureDefaultBuildTask(); return; } <del> this.run(task, { attachProblemMatcher: true }).then(undefined, reason => { </del> <ins> this.run(task, { attachProblemMatcher: true }, TaskRunSource.User).then(undefined, reason => { </ins> // eat the error, it has already been surfaced to the user and we don't care about it here }); });

Discussion:
Issue Type: <bBug</bRecent update to 1.48.0 seems to have killed sorting the Run Build Task list by most recently used. In fact, the list doesn't appear to change order at all (not sorting lexicographically, either). VS Code version: Code 1.48.0 (, 2020-08-13T07:50:42.600Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (7)</summaryExtensionVersion ------ vscode-open-in-application1.0.5 cortex-debug0.3.7 cpptools0.29.0 cmake0.0.17 vscodeintellicode1.2.10 clang-format1.9.0 linkerscript1.0.1 </details<!-- generated by issue reporter --
To verify: Open a folder with build tasks, such as the VS Code repo. If you use the VS Code repo, in the change the of the task to simply be (no ). Run the Tasks: Run Build Task command Choose a build task and run it from that quick pick Run the Tasks: Run Build Task command again. Verify that the task you just ran shows at the top of the list in the recently used section. Repeat with another build task.
Verified in Version: 1.48.1 Commit: Date: 2020-08-18T17:06:48.722Z
Change:
if (this.canSelectMany) { this.ui.list.domFocus(); } <del> event.preventDefault(); </del> <ins> dom.EventHelper.stop(event, true); </ins> break; case KeyCode.UpArrow: if (this.ui.list.getFocusedElements().length) {

Discussion:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- 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.44.2 OS Version: Ubuntu 19.10 Steps to Reproduce: navigate editors through QuickOpen "navigate next" and "navigate previous" work as "navigate next after next" and "navigate previous of previous". So simply said it skip next/previous editor. Here are keybindings I use ` works ok, but and don't <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
PR: The issue is that we are listening to keys within the quick input control to do certain things but we do not prevent bubbling. This means our keybinding service will also receive these keys and check for actions to perform. In the old quick open widget we always prevented bubbling for that reason.