jiebi/CodeConvo huggingface dataset:
Change:
} this._updateAriaLabel(); <del> this._setFocusedComment(this._focusedComment); </del> <ins> if (!preserveFocus) { this._setFocusedComment(this._focusedComment); } </ins> } private _updateAriaLabel() {

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 <!-- 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.0 (Universal) OS Version: macOS Ventura 13.3.1 (a) Steps to Reproduce: a comment thread with multiple replies. on "Reply". typing a response. write , e.g. to add new replies fetched in the background by the extension. Focus is removed from the Reply input when the comment list renders. When the Reply input is open but empty, this will also close the input again, which is jarring. ! Expected behavior would be that updates to earlier replies (at least as long as they preserve ) do not affect focus. When the Reply input is empty, it should remain open if new comments come in. cc
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.1. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
To clarify our use case a bit more: we don't expect background updates to happening frequently (i.e. not live collaboration similar to Google Docs) but we might occasionally still receive a single new round of comments from a reviewer while the change author is currently typing a reply. As far as I know there is no way for our extension to learn if the Reply input is open with pending content, meaning we cannot delay automatic background updates to wait until we won't interrupt the user.
Focus goes back to so it appears to be lost, not stolen.
It's a surprising and inconvenient behavior that updating fields in vscode.CommentThread steals focus.

It'd be great if the APIs are updated not to steal the focus. Our extension (for Gerrit code review integration) has a method to decorate a vscode.CommentThread, which currently always updates all the CommenThread's fields even if there's a field having no change. This construct makes the implementation simple, removing the need of checking the equality for every field. All was good - until we realized the bug of the focus being stolen at an unexpected timing while the user is editing the code. We will workaround the issue by introducing equality check everywhere, but I hope we could remove the workaround in future.
Change:
return previewValue; } <del> private stripIndentationFromPreviewRange(textEditorModel: ITextModel, startLineNumber: number, previewRange: Range) { </del> <ins> private stripIndentationFromPreviewRange(textEditorModel: ITextModel, startLineNumber: number, previewRange: IRange) { </ins> const startIndent = textEditorModel.getLineFirstNonWhitespaceColumn(startLineNumber); let minIndent = startIndent;

Discussion:
Issue Type: <bBug</bGitHub Pull Request extension repo Hover on Press CMD key ! Ideally we should be able to implementation of at the top and definition at the bottom, but :( VS Code version: Code - Insiders 1.34.0-insider (, 2019-04-09T05:14:40.620Z) OS version: Darwin x64 18.5.0 <details<summarySystem Info</summary </details<details<summaryExtensions (50)</summaryExtensionVersion ------ vscode-apollo1.5.2 markdown-emoji0.0.7 solargraph0.19.6 npm-intellisense1.3.0 vscode-svgviewer2.0.0 vscode-markdownlint0.26.0 vscode-eslint1.8.2 xml2.4.0 gitlens9.6.0 remotehub0.2.0 tsl-problem-matcher0.0.4 EditorConfig0.13.0 tslint1.0.43 vscode-npm-script0.3.5 vsc-material-theme2.8.2 prettier-vscode1.8.1 flow-for-vscode1.1.1 vscode-pull-request-github-insiders1.98.0 ocaml0.6.43 beautify1.4.11 references-plusplus0.0.5 graphql-for-vscode1.13.0 dotenv1.0.1 theme-monokai-pro-vscode1.1.12 vscode-azurefunctions0.16.0 vscode-language-pack-zh-hans1.33.2 python2019.3.6558 azure-account0.8.1 cpptools0.22.1 Go0.9.2 powershell1.12.0 vscode-typescript-tslint-plugin1.0.0 wordcount0.1.0 vsliveshare1.0.18 debugger-for-chrome4.11.3 debugger-for-ios-web0.1.2 vetur0.18.1 subtitles-editor1.0.2 vscode-versionlens0.22.0 material-icon-theme3.7.0 seti-icons0.1.3 ruby0.22.3 smartpaste0.0.3 toggle0.0.1 vscode-fuzzsymbols0.0.1 sass-indented1.5.1 rust0.6.1 sourcekit-lsp0.0.

1 vscode-lldb1.2.2 vscode-intelli-nav0.0.6 (12 theme extensions excluded) </details<!-- generated by issue reporter --
adding since I believe the implementation peak when holding CMD is determined by VS Code
Yeah, today we count matching bracket (up to a low maximum of lines) to compute the preview. not sure if TypeScript provides  but that would certainly help here
Ok, we do set the but it is just the range of the identifier (). I've opened to track having this information returned from TypeScript
Planning to do work to support API proposed by in June. We would not actually ship this until TS 3.6 however
To verify, please make sure you are using TS 3.6 in your workspace and follow original instructions in the github PR extension's codebase
Change:
} .monaco-editor .margin-view-overlays .comment-range-glyph.line-hover, <del> .monaco-editor .margin-view-overlays .comment-range-glyph.comment-thread { </del> <ins> .monaco-editor .margin-view-overlays .comment-range-glyph.comment-thread, .monaco-editor .margin-view-overlays .comment-range-glyph.comment-thread-unresolved { </ins> margin-left: 13px; } .monaco-editor .margin-view-overlays > div:hover > .comment-range-glyph.comment-diff-added:before, .monaco-editor .margin-view-overlays .comment-range-glyph.line-hover:before, <del> .monaco-editor .comment-range-glyph.comment-thread:before { </del> <ins> .monaco-editor .comment-range-glyph.comment-thread:before, .monaco-editor .comment-range-glyph.comment-thread-unresolved:before { </ins> position: absolute; height: 100%; width: 9px;

Discussion:
Comments in the editor have a different color based on their resolved status. We could do something similar for the icon in the gutter, and make obvious which comment is resolved even when comments are folded. Maybe change the icon color? Or use a different icon? (also related to )
Example of how it currently looks: ! Example with adjusted colours: ! Note that colour alone is not a full solution since it is not that accessible, but I think it should be included in the final solution.
A different icon/unicode character for resolved would be good here.
Let's get done first.
Change:
private async _viewResourceGroupChanges(repository: Repository, resourceGroup: GitResourceGroup): Promise<void> { if (resourceGroup.resourceStates.length === 0) { <ins> switch (resourceGroup.id) { case 'index': window.showInformationMessage(l10n.t('The repository does not have any staged changes.')); break; case 'workingTree': window.showInformationMessage(l10n.t('The repository does not have any changes.')); break; case 'untracked': window.showInformationMessage(l10n.t('The repository does not have any untracked changes.')); break; } </ins> return; }

Discussion:
Testing When running when there are no staged changes doesn't do anything. That's a but confusing. E.g. in the case of multi-folder workspace, I first get prompted for the repo, I select an entry, but then nothing happens It could show a notification, but IMO it would be better to show the empty multi-editor. An empty multi-editor is already shown when you stage all entries in it
I also agree it would be better to show a empty multi-editor this happened to me when I binding different keys to these command and I kept getting confused that I wasn't using the right keyboard shortcuts because nothing would happen when I did them.
Decided to go with notifications as that is consistent with the other commands contributed by the git extension.
Change:
7z.exe a .build/node_modules_cache/cache.7z -mx3 `@.build/node_modules_list.txt - name: Compile and Download <del> run: yarn npm-run-all --max_old_space_size=4095 -lp compile "electron x64" playwright-install download-builtin-extensions </del> <ins> run: yarn npm-run-all --max-old-space-size=4095 -lp compile "electron x64" playwright-install download-builtin-extensions </ins> - name: Compile Integration Tests run: yarn --cwd test/integration/browser compile

Discussion:
Builds:
fyi
Attempting a fix by simply doubling the max memory available to V8.
Again in
Then I'm out of ideas. we might need to split all those mangling tasks into independent processes, if memory limits are being hit.
Are we sure that we are on the right track here? According to my counting (below) we have only a tenth of the code in extensions (compare to the src-folder) so I wonder why mangling would eat up so much memory here?
I am not sure OOM is the symptom here actually, just my best hunch, but it seems is indeed the problem: <img width="913" alt="image" src=""
Added a every 1 second log of memory usage to this task: Build running:
Created to log the memory usage after each mangling step
lol - similar idea here:
I think we are on to something here. The memory is growing a lot, maybe some state leaks when mangling the next extension. Each extension is its own tsconfig and mangling context. This shouldn't pile up but memory should be released inbetween
Can you take a look at this? I put my money on this which keeps its mangler around. Looks like we need some webpack hook to dispose that loader
I gave it a stab at for which I have confidence, running locally shows how memory is growing and shrinking! This isn't a webpack change but just some cleanup in the mangler itself
!
Change:
var result = this.gitService.checkout(this.branch.name).then(null, (err) => { if (err.gitErrorCode === GitErrorCodes.DirtyWorkTree) { <del> return Promise.wrapError(new Error(nls.localize('dirtyTreeCheckout', "Can't checkout. Please commit or stage your work first."))); </del> <ins> return Promise.wrapError(new Error(nls.localize('dirtyTreeCheckout', "Can't checkout. Please commit or stash your work first."))); </ins> } return Promise.wrapError(err);

Discussion:
VSCode Version: 1.7.2 OS Version: 10.12.1 Steps to Reproduce: a project that is linked to remote a git repositoty. a clone in another dir or ask a friend to modify a file, commit, and push. the same file locally and try to pull. You will get an error saying (emphasis mine): Meanwhile, in the git console you see a different and correct error: The error is that "stash" is the correct action, staging won't help. Here is the line
Fixed by
Change:
for (const codeActionKind of codeActionsOnSave) { const actionsToRun = await this.getActionsToRun(model, codeActionKind, excludes, getActionProgress, token); <ins> if (token.isCancellationRequested) { actionsToRun.dispose(); return; } </ins> try { for (const action of actionsToRun.validActions) { progress.report({ message: localize('codeAction.apply', "Applying code action '{0}'.", action.action.title) }); <del> await this.instantiationService.invokeFunction(applyCodeAction, action, ApplyCodeActionReason.OnSave); </del> <ins> await this.instantiationService.invokeFunction(applyCodeAction, action, ApplyCodeActionReason.OnSave, {}, token); if (token.isCancellationRequested) { return; } </ins> } } catch { // Failure to apply a code action should not block other on save actions

Discussion:
re testing select some TS code that can be extracted as const select refactor with preview select extract const select discard :bug: the rename widget still shows... https://user-
I believe fixing this requires some info being returned from the bulk edit service, e.g the service should tell its caller that the change didn't happen so that code actions don't continue the normal flow
Change:
//#endregion <del> //#region allow title property to QuickPickOptions/InputBoxOptions: https://github.com/microsoft/vscode/issues/77423 interface QuickPickOptions { /** * An optional string that represents the tile of the quick pick. */ title?: string; } interface InputBoxOptions { /** * An optional string that represents the tile of the input box. */ title?: string; } //#endregion </del> //#region https://github.com/microsoft/vscode/issues/106744, Notebooks (misc) export enum NotebookCellKind {

Discussion:
Currently, can only be set when going through the more complex API. It would be great if the title could be set via when using the simpler .
proposal: for quickpick or Input: This basically meshes with UI in: and in the class itself here: cc
what extensions have to do now in order to get the base functionality + a title:
In API sync there was no pushback or additional comments. I have moved to implementation ^
I will reopen this for API finalization next week.
This was covered on so there's nothing else to do here besides wait for the next release of vscode types :)
Change:
}, [treeStickyScrollMaxElements]: { type: 'number', <ins> minimum: 1, </ins> default: 5, markdownDescription: localize('sticky scroll maximum items', "Controls the number of sticky elements displayed in the tree when `#workbench.tree.enableStickyScroll#` is enabled."), },

Discussion:
Testing In the setting definition all minimum/maximum in order to get input validation in the settings editor. <img width="896" alt="image" src=""
Good catch. Will set a min value. Don't think a max value is needed though.
Change:
const completionText = completion.completionText ?? completion.label; const finalCompletionRightSide = completionText.substring((this._leadingLineContent?.length ?? 0) - (lastSpaceIndex === -1 ? 0 : lastSpaceIndex + 1)); <ins> // Hide the widget if there is no change if (finalCompletionRightSide === additionalInput) { this.hideSuggestWidget(); return; } </ins> // Get the final completion on the right side of the cursor if it differs from the initial // propmt input state let finalCompletionLeftSide = completionText.substring(0, (this._leadingLineContent?.length ?? 0) - (lastSpaceIndex === -1 ? 0 : lastSpaceIndex + 1));

Discussion:
Steps to Reproduce: and press :bug: intellisense completion was for the argument instead of running the command I have a pretty strong muscle memory to run that command, so now I need to remember to press escape before pressing enter !
this is bad enough that I've turned the feature off, I can't even use
I also hit these issues particularly with : ! !
one change that would make this much less painful: ctrl+z should undo the auto-complete change as a single action (as is the case with the text editor). I press enter really quickly, after typing what I want, and if auto-complete provides something I didn't want, ctrl+z will undo one character at a time.
Well powershell does support ctrl+z itself. We may be able to undo everything, or nearly everything by using bracketed paste mode, since you can paste something and undo it fine.
Just tried with Posh-Git and while the commands () and aliases ( in mine) work, it still doesn't suggest after checkout: <img width="859" alt="Screenshot 2024-06-14 at 9 56 45 AM" src=""
doesn't show files/folders so we couldn't use that. Maybe using the current completion call, but also providing , , etc. when there are only and entries?
Looks promising <img width="861" alt="Screenshot 2024-06-14 at 10 11 11 AM" src=""
Change:
} const text = getXtermLineContent(this._xterm.buffer.active, startLine, endLine, this._xterm.cols); <ins> if (text.length > MAX_LENGTH) { return []; } </ins> // clone regex to do a global search on text const rex = new RegExp(this._localLinkRegex, 'g');

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.47.0-insider OS Version: Win 10 1909 Steps to Reproduce: this link in your terminal: over it. Observe that the UI starts lagging <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes

<!-- 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: stable and from sources Steps to Reproduce: terminal and run a program that prints a really long line. For example the mouse over the text in the terminal and start scrolling up and down :bug: observe the terminal lags while scrolling
I believe this is already fixed, can you see if you can reproduce in the ? !
it's an issue in the terminal not in the debug console
I see. Could you pls send a gif of this? I tried scrolling in the terminal and wasn't seeing any lag.
Sure, notice int the gif I'm scrolling up ! I created a PR with a fix you can check the root cause is while executing a regex in
I verified that your PR fixes this bug , but will await 's approval of the changes.
/duplicate
Change:
"scope": "markup.inline.raw", "settings": { "fontStyle": "", <del> "foreground": "#AB6526" </del> <ins> "foreground": "#9C5D27" </ins> } }, {

Discussion:
Environment Details: VSCode Version : 1.24.0 OS Version : Win10 Additional Details: MAS Violated : MAS 1.4.3 Tools Used : Color Contrast Analyzer Repro Steps: 1)Navigate to Settings--Select color theme --Select Quiet light. 2)Check color contrast ratio for the Explorer content on the screen. Actual: Color contrast ratio is less than 4.5:1 for the black colored content when focused. Similar issue is observed in following themes: Abyss Kimbie dark Monokai Dimmed High contrast Install additional color theme Expected: Color contrast ratio should be more than 4.5:1 for the content on a screen. Recommendations: Refer below link which is repository of bug fixes code snippets:   User Impact: The low vision/visually impaired users will not be able to view the content properly. MAS Reference: MAS 1.4.3 - {-765f-489c-b18f-}  Attachment For Reference: ! Does this issue occur when all extensions are disabled?: Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.981 --- <!-- score: 0.924 --- <!-- score: 0.875 --- <!-- score: 0.869 --- <!-- score: 0.867 --<!-- potentialduplicates_comment --
Per our agreement, we will not be fixing color contrast issues with third party themes. cc
just a note that we are the authors of this theme (actually I am the original author) Does this mean that we only fix for the Light+ and Dark+?
we're supposed to fix any issues for themes that we own and ship with out of the box (except for third party themes we don't own). I didn't know we own QuietLight so I'll re-open.
Checked and verified in below version i.e 1.27.0-Insiders. The issue still exist in Quite Light theme. Similar issue is observed in following themes: 1)Solarized light:All the text in the page fail in color contrast ratio i.e 4.5:1 2)Light visual studio: Black coloured text fail in color contrast ratio i.e 4.5:1
please see for the unused variable color issues
Change:
<del> # --------------------------------------------------------------------------------------------- #   Copyright (c) Microsoft Corporation. All rights reserved. #   Licensed under the MIT License. See License.txt in the project root for license information. # --------------------------------------------------------------------------------------------- autoload -Uz add-zsh-hook IN_COMMAND_EXECUTION="1" LAST_HISTORY_ID=0 prompt_start() { printf "033]633;A007" } prompt_end() { printf "033]633;B007" } update_cwd() { printf "033]633;P;Cwd=%s007" "$PWD" } command_output_start() { printf "033]633;C007" } continuation_start() { printf "033]633;F007" } continuation_end() { printf "033]633;G007" } command_complete() { local HISTORY_ID=$(history | tail -n1 | awk '{print $1;}') if [[ "$HISTORY_ID" == "$LAST_HISTORY_ID" ]]; then printf "033]633;D007" else printf "033]633;D;%s007" "$STATUS" LAST_HISTORY_ID=$HISTORY_ID fi update_cwd } update_prompt() { PRIOR_PROMPT="$PS1" IN_COMMAND_EXECUTION="" PS1="$(prompt_start)$PREFIX$PS1$(prompt_end)" PS2="$(continuation_start)$PS2$(continuation_end)" } precmd() { local STATUS="$?" if [ -z "${IN_COMMAND_EXECUTION-}" ]; then # not in command execution command_output_start fi command_complete "$STATUS" # in command execution if [ -n "$IN_COMMAND_EXECUTION" ]; then # non null update_prompt fi } preexec() { PS1="$PRIOR_PROMPT" IN_COMMAND_EXECUTION="1" command_output_start } add-zsh-hook precmd precmd add-zsh-hook preexec preexec # Show the welcome message if [ -z "${VSCODE_SHELL_HIDE_WELCOME-}" ]; then echo "033[1;32mShell integration activated033[0m" else VSCODE_SHELL_HIDE_WELCOME="" fi </del>

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 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.65.0-insider OS Version: MacOS12.2.2 Steps to Reproduce: with setting new terminal <img width="1440" alt="image" src="https://user-"
Thanks, we're aware of this issue and have been working toward its resolution
Change:
toNamespacedPath(path: string): string { // Note: this will *probably* throw somewhere. <del> if (typeof path !== 'string') { </del> <ins> if (typeof path !== 'string' || path.length === 0) { </ins> return path; } <del> if (path.length === 0) { return ''; } </del> const resolvedPath = win32.resolve(path); if (resolvedPath.length <= 2) {

Discussion:
We will ship Electron with to stable soon so we should also look into bringing our copy of library to the same version. Checking for the diff, it seems to be a few commits after and up until //cc
Hm, the first change is already pretty bad for us: Because it seems to depend on a new thing which is maybe defined globally and probably optimised / cached / snapshotted. Maybe we should rather look out for actual bug fixes and focus on those... Changes: I think only the 2 fix commits stand out from the others
I assume you skipped over right?
Reopening given unit test failures, I had to revert the change for now.
yes I skipped the primordials. I didn't dig into why they do this, but it seemed easy enough to just call the string functions instead. As for the test failures, new PR
Primordials are only meant for Nodejs internal code usage, external users should just replace them with corresponding JavaScript builtins. You can read more about why Nodejs does it