jiebi/CodeConvo huggingface dataset:
Code change:
builtin printf "e]633;P;ContinuationPrompt=$(echo "$PS2" | sed 's/x1b/x1b/g')a" __vsc_report_prompt() { <ins> # HACK: Git bash is too slow at reporting the prompt, so skip for now if [ "$__vsc_is_windows" = "1" ]; then return fi </ins> # Expand the original PS1 similarly to how bash would normally # See https://stackoverflow.com/a/37137981 for technique if ((BASH_VERSINFO[0] >= 5 || (BASH_VERSINFO[0] == 4 && BASH_VERSINFO[1] >= 4))); then

Related discussion:
text: Type: <bBug</bterminal git bash Enter and you will get delay VS Code version: Code - Insiders 1.90.0-insider (, 2024-05-06T08:07:13.626Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (42)</summaryExtensionVersion ------ rust-bundle1.0.0 glance0.0.8 project-manager12.8.0 redmodscript-lang0.2.0 redmodtweak-lang0.1.0 lit-html1.11.1 glsl-literal1.0.6 vscode-markdownlint0.55.0 vscode-eslint2.4.4 composer-php-vscode1.45. intelli-php-vscode0.12. phptools-vscode1.45. profiler-php-vscode1.45. rust-syntax0.6.1 gitlens14.9.1 EditorConfig0.16.4 prettier-vscode10.4.0 auto-close-tag0.5.15 auto-rename-tag0.1.10 copilot1.186.856 copilot-chat0.16. todo-tree0.0.226 path-autocomplete1.25.0 redscript-syntax-highlighting0.0.3 auto-comment-blocks1.0.1 dotenv1.0.1 debugpy2024.6.0 python2024.6.0 vscode-pylance2024.4.1 remote-wsl0.88.2 hexeditor1.10.0 vscode-extension-auto-import1.4.3 indent-rainbow8.3.1 vscode-yaml1.14.0 rust-analyzer0.3.1950 crates0.6.6 shader1.1.5 vscode-styled-components1.7.8 vscode-stylelint1.4.0 vscode-mdx1.8.4 highlight-matching-tag0.11.0 vscode-import-cost3.3.0 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
does this reproduce if you disable shell integration, ?
If I uncheck Shell Integration, it works well after terminal restart.
I have more details in with what's going wrong.
Code change:
builtin printf "e]633;P;ContinuationPrompt=$(echo "$PS2" | sed 's/x1b/x1b/g')a" __vsc_report_prompt() { <ins> # HACK: Git bash is too slow at reporting the prompt, so skip for now if [ "$__vsc_is_windows" = "1" ]; then return fi </ins> # Expand the original PS1 similarly to how bash would normally # See https://stackoverflow.com/a/37137981 for technique if ((BASH_VERSINFO[0] >= 5 || (BASH_VERSINFO[0] == 4 && BASH_VERSINFO[1] >= 4))); then

Related discussion:
text: The issue was introduced by this PR where becomes extremely slow
I had the same issue and setting to does the trick.
When I just hit the enter key on a bash prompt it takes about 4 seconds for the prompt to return. I ran process monitor and noticed many many (maybe over a hundred) instances of being spawned to run the shellIntegration- script.
Any idea where this ticket is tracked? Every reference to the issue is closed marking duplicate.
Closing an unfixed issue that everyone have ? I don't get the point
I closed this accidentally, have reopened.
worked for me !
Hey guys I'm having the same issue. Running a single is taking over 15 seconds to complete the command. After disabling , bash looks way better
The problem seems to be related to The issue happens also if I start (outside VsCode) my bash thus (same as VsCode does for its terminal): Each time the prompt must be shown (eg, after simply pressing the Enter key) a delay of about two seconds happens. Most of the delay is caused, it seems, by the function In particular, commenting out the line 178 seems to alleviate good part (not all) of the delay. Edit: More specifically, the culprit seems to be If I change the line 109 from to (effectively forcing "the switch to the faster function"), the problem goes away. (BTW: the faster function seems to have a bug of its own, it produces an extra prompt!)
Process monitor screenshot shows it re-running this over and over 89 times when I press enter at the shell prompt "C:Program FilesGitbin..usrbin" --init-file "c:UsersarthuAppDataLocalProgramsMicrosoft VS Coderesourcesapp/out/vs/workbench/contrib/terminal/browser/media/shellIntegration-" !
Disabling is another workaround that improves the delay for me.
Hello Guys, This setting worked for me.
This helped me, thanks!
will move you to the old backend stack which significantly reduces the functionality/capabilities of the terminal. shouldn't do anything. is the right workaround for now, expect a fix soon though
what caused so many bash invocations when shell integration is enabled?
we started reporting the bash prompt in order to better position shell integration markers and understand the prompt.
Code change:
builtin printf "e]633;P;ContinuationPrompt=$(echo "$PS2" | sed 's/x1b/x1b/g')a" __vsc_report_prompt() { <ins> # HACK: Git bash is too slow at reporting the prompt, so skip for now if [ "$__vsc_is_windows" = "1" ]; then return fi </ins> # Expand the original PS1 similarly to how bash would normally # See https://stackoverflow.com/a/37137981 for technique if ((BASH_VERSINFO[0] >= 5 || (BASH_VERSINFO[0] == 4 && BASH_VERSINFO[1] >= 4))); then

Related discussion:
text: Apparently printf is just extremely slow on git bash
I had this terminal slowdown problem, in git bash, and found setting fixed the problem - the terminal was back to being fast. However, after the last, or recent, insiders update, even with that setting set to , the terminal is slow again - and it's showing the icons, etc. like it is ignoring this setting: ! !
you probably just didn't restart the terminal. This is now fixed and will come in the next Insiders and likely 1.90.1
Actually, I had the shell integration disabled for the last several insiders updates, so it has been off for a while. Terminal windows have been created and closed many time since. For whatever reason, when launching VSCode and the terminal session was restored, this last time, the integration feature was ignoring the flag. I terminated the terminal and started another, and the integration went away again. So basically the integration flag was ignored when the terminal session was restored. I just did a quick test of quitting VSCode, with a terminal window open, then relaunching, and the integration was still disabled. Unsure what happened. Guessing, also, you type-o-ed the version? I am already running 1.91.0 insider !
what happened was the terminal was restored which re-creates the process after vscode starts with the original environment, args, etc. No the next insiders build on Monday and v1.90.1 (stable)
when will be the next minor update, not the insider build so this terminal slowness is resolved?
FWIW, I can also observe the prompt's slowness on Linux (bash 5.1.16(1)-release on Ubuntu 22.04.4 LTS) on the order of a half-second or so (still annoying but bearable). looks like a temporary workaround for Git Bash only; will we fix the underlying cause of the slowness?
I also observe this to be slow over linux using an ssh remote. It's much slower if I have a starship prompt enabled (4s) and around 1s if I have the default debian prompt.
I have this issue (Win 10, git bash). The suggested workaround of disabling shell integration then restarting terminals worked for me.
Also having this problem. Disable terminal integration worked for me too. (Win 11, Git bash).
Code change:
builtin printf "e]633;P;ContinuationPrompt=$(echo "$PS2" | sed 's/x1b/x1b/g')a" __vsc_report_prompt() { <ins> # HACK: Git bash is too slow at reporting the prompt, so skip for now if [ "$__vsc_is_windows" = "1" ]; then return fi </ins> # Expand the original PS1 similarly to how bash would normally # See https://stackoverflow.com/a/37137981 for technique if ((BASH_VERSINFO[0] >= 5 || (BASH_VERSINFO[0] == 4 && BASH_VERSINFO[1] >= 4))); then

Related discussion:
text: I re-enabled terminal integration with the latest Insiders - ! and it the problem seems to have been fixed. For me at least.
Yes, it's been fixed in insider's already.
Perfect solution
When is the release date for the VSCode stable one?
no exact date, but probably later this week
, Turning off shell integration only sorta helped me out. It does return a result slightly faster, but it does not return the prompt back for 4 seconds or so, but only with python poetry workspaces/folders opened. This slowness goes away if I don't have a workspace/folder open, a non-poetry python one, a javascript one, etc. There's now a '(packagename-pythonversion)' at the top of my prompt when I open a python poetry folder and that seems to be taking forever to generate after each command. Definitely wasn't happening before my last update. This seems like a separate issue? Or is it related somehow? Happy to open a separate Issue if needed.
I don't know if this is the same as your issue but I've found that, if I already opened a terminal in a workspace before changing the setting, I had to kill the terminal for that workspace and open a new one so it would be initiated with the updated setting.
Yes. With the feature disabled, issue does not happen . But the feature will not work also . I can live without that feature but I like it. It makes my IDE look smarter. It's strange. I remember the feature was there earlier without any issue.
Was the fix included in 1.90.1? The shell integration is still too slow even after I updated to 1.90.1. It still takes over a second for all those bash commands to run every time press the enter key at the terminal. I have to keep it off to keep my Windows git bash terminal usable. It seems like it takes around a second and a half to get a new prompt with that setting on. Is this expected?
Code change:
builtin printf "e]633;P;ContinuationPrompt=$(echo "$PS2" | sed 's/x1b/x1b/g')a" __vsc_report_prompt() { <ins> # HACK: Git bash is too slow at reporting the prompt, so skip for now if [ "$__vsc_is_windows" = "1" ]; then return fi </ins> # Expand the original PS1 similarly to how bash would normally # See https://stackoverflow.com/a/37137981 for technique if ((BASH_VERSINFO[0] >= 5 || (BASH_VERSINFO[0] == 4 && BASH_VERSINFO[1] >= 4))); then

Related discussion:
text: I just updated to this version: Version: 1.90.1 (user setup) Commit: Date: 2024-06-11T21:01:24.262Z Electron: 29.4.0 ElectronBuildId: Chromium: 122.0.6261.156 20.9.0 V8: 12.2.281.27-electron.0 OS: Windows_NT x64 10.0.
it should be fixed yes, can you run and paste in the results?
$ for i in {1..10}; do time _vscreport_prompt; done real 0m0.236s user 0m0.045s sys 0m0.092s real 0m0.194s user 0m0.045s sys 0m0.076s real 0m0.210s user 0m0.030s sys 0m0.122s real 0m0.217s user 0m0.015s sys 0m0.152s real 0m0.216s user 0m0.061s sys 0m0.138s real 0m0.245s user 0m0.045s sys 0m0.123s real 0m0.202s user 0m0.015s sys 0m0.091s real 0m0.212s user 0m0.061s sys 0m0.091s real 0m0.230s user 0m0.000s sys 0m0.153s real 0m0.212s user 0m0.045s sys 0m0.108s
It seems like it's taking a long time to parse the prompt. My git bash prompt is user MINGW64 /c/path/to/dir (master), where the my /c/path/to/dir is a 29 character path. But sometimes it's a lot longer. Does a longer path make it slower?
Code change:
builtin printf "e]633;P;ContinuationPrompt=$(echo "$PS2" | sed 's/x1b/x1b/g')a" __vsc_report_prompt() { <ins> # HACK: Git bash is too slow at reporting the prompt, so skip for now if [ "$__vsc_is_windows" = "1" ]; then return fi </ins> # Expand the original PS1 similarly to how bash would normally # See https://stackoverflow.com/a/37137981 for technique if ((BASH_VERSINFO[0] >= 5 || (BASH_VERSINFO[0] == 4 && BASH_VERSINFO[1] >= 4))); then

Related discussion:
text: When I cd to a 135 character path, and try to time it it just prints 633;D;0: $ time vscreportprompt 633;D;0 $ vscreportprompt 633;D;0
those numbers aren't too bad, but regardless I think we need to rethink how we're doing this prompt reporting feature. I'm going to stick it behind a setting in so it's just disabled completely by default.
This is still unreasonably slow, IMO. If I'm running a shell with the extensions the shortest possible interval between two commands seems to be over 700ms on my machine: ! Running without the shell integration, it's closer to 250ms, and that may only be because that's how fast I can press the ⇧⏎⇧⏎ keys: ! Despite the improvement over 1.90.0, I still feel like I have to disable the shell integration. It's 2024. Having to wait a perceptible amount of time just for the terminal prompt to re-appear feels like a huge regression to 1980s computing. Is my floppy drive trying to seek to a specific sector?
v1.91 which I think is being released today includes the changes I mentioned in , disabling the prompt reporting stuff completely (for the stable build): !
I'm running 1.91.0 (insiders) and I still see a significant delay between prompts (on windows, using git-bash terminal). Turning the shell integration off speeds it up quite a bit.
it's only disabled in the stable build. Insiders keeps the slower code as it provided reliability improvements and the plan is to optimize it soon.
While v1.91 does seem to improve the delay, there's still a noticeable delay for me so I'll be sticking with the option disabled.
Code change:
const keybindingsExtPoint = ExtensionsRegistry.registerExtensionPoint<ContributedKeyBinding | ContributedKeyBinding[]>({ extensionPoint: 'keybindings', <ins> deps: [commandsExtensionPoint], </ins> jsonSchema: { description: nls.localize('vscode.extension.contributes.keybindings', "Contributes keybindings."), oneOf: [

Related discussion:
text: contribute command that uses enablement assign a keybinding, via :bug: enablement isn't honoured
When users configure keybindings we allow them to change preconditions as well, e.g rename requires an editable document so I don't plan to have a different strategy for contributed commands
I don't see the nice "Command 'Hello World' is not enabled in the current context." info toast when I try the keybinding though. I only see that message when I try to run it from the command palette. The command correctly doesn't run when not enabled though.
Yeah, that's the design. Keybindings don't show messages
Code change:
} const index = this.mustGetTaskIndex(taskId); <ins> const oldTerminalStatePrio = terminalStatePriorities[entry.tasks[index].state]; const newTerminalStatePrio = terminalStatePriorities[state]; // Ignore requests to set the state from one terminal state back to a // "lower" one, e.g. from failed back to passed: if (oldTerminalStatePrio !== undefined && (newTerminalStatePrio === undefined || newTerminalStatePrio < oldTerminalStatePrio)) { return; } </ins> this.fireUpdateAndRefresh(entry, index, state, duration); }

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. --<!-- 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.64.0-insider () In the Catch2 C++ test framework it is possible to have multiple test results for the same test in one run. This happens for example for the following code: In this scenario, the section "S" is run twice, and the first time it fails, the second time it succeeds. The C++ TestMate extension will see the two test runs, and call for the first one, and for the second, with the same for both calls. This results in the confusing display that the section is green, even though it shows a failure inside: <img width="653" alt="image" src="https://user-" does it make sense to change and (et al) so that when called multiple times, it sets the item's state to the max of the old and the new state? This seems to be analogous to what happens with the test messages (they are appended, and doesn't clear them). Or would you say it's the extension's responsibility to not set the state more than once for a given TestItem? (Cc Or maybe it is even Catch2's responsibility to accumulate the results for any section that is run more than once?
IMHO, Catch2 reports it and definitely not the responsibility of vscode. It leaves it to me.. (Though I don't know how I can solve this properly)
Why definitely? It doesn't seem so unreasonable to me. As I said, it already does something similar with the test messages.
As I think of it, vscode part is just the UI, the controlling is in my hand. More precisely and . the test provider is the .
Code change:
} const index = this.mustGetTaskIndex(taskId); <ins> const oldTerminalStatePrio = terminalStatePriorities[entry.tasks[index].state]; const newTerminalStatePrio = terminalStatePriorities[state]; // Ignore requests to set the state from one terminal state back to a // "lower" one, e.g. from failed back to passed: if (oldTerminalStatePrio !== undefined && (newTerminalStatePrio === undefined || newTerminalStatePrio < oldTerminalStatePrio)) { return; } </ins> this.fireUpdateAndRefresh(entry, index, state, duration); }

Related discussion:
text: I'm not so sure in this case. VS Code is also responsible for setting T's state correctly, you don't do that at all (as far as I'm aware). And note that it gets that one right, so it has some logic already for computing the resulting state of all child runs if there are multiple for the same item.
I would be very interested in your opinion on this.
Yea, I think it would be reasonable to no-op if the extension tries to change the test state to one with a lower priority. For instance, going from passed-skipped or failed-passed.
can you add some steps?
the test sample: this block F5.Verify that, with these changes, test that should pass remain passed in the UI, and tests that failed remain failed.
Code change:
if (this.widget.viewModel) { this.chatService.clearSession(this.widget.viewModel.sessionId); } <ins> this.viewState.inputValue = ''; </ins> this.updateModel(); }

Related discussion:
text: I use quite a lot and have noticed that sometimes earlier queries are restored after runs. AFAICT it might be because when we run , the restores the input value from the saved view state, which can be stale
Blocked on verifying by
you can work around that issue by manually typing /clear into the input box, that issue only applies to when /clear is selected from the suggest widget
Code change:
return; } <ins> if (e.browserEvent.defaultPrevented) { return; } </ins> super.onDoubleClick(e); } }

Related discussion:
text: see gif open GH notebook with a few cell that reference a variable run peek references and select entries notice how notebook cells are being highlighted, like "Milestone Work" get selected !
I can repro in Insiders but not master, I'll check again tomorrow
This happens because of this listener: Tho, not yet sure why the selection keeps changing... Maybe some inner list event (from the references list) bubbles up to the outer list
That listener is fine, it's the nested lists
Hey do you have any thoughts on handling this? We have a list inside another list. The inner list handles the touch event properly. The outer list then handles the event and picks up the wrong index because it finds the data attribute inside the inner list in We can Make sure the event is fired on the outer list with the correct element, by fixing to check whether it's in the right list Not fire the event on the outer list at all, when we see that it originates in a different list Add some property to the list event that says it originated in a different list so the consumer can decide In this particular case, I think any of these are fine
Thinking more, I don't think that the event should ever be handled by two lists at all. Meaning we either mark the browserEvent as handled, like with preventDefault/isDefaultPrevented, or we make the list check every event to be sure that it originated in this list.
This sounds good to me. This also sounds good to me.
related when I do peek references, I see markdown cells being selected? ! Notice I'm looking for under-discussion but "Configure" is being highlighted as one of the references
From Good catch, I didn't notice that
Thanks for the quick handling!
Code change:
} this._currentCommand.commandFinishedMarker = this._terminal.registerMarker(0); <del> const command = this._currentCommand.command; </del> <ins> let command = this._currentCommand.command; </ins> this._logService.debug('CommandDetectionCapability#handleCommandFinished', this._terminal.buffer.active.cursorX, this._currentCommand.commandFinishedMarker?.line, this._currentCommand.command, this._currentCommand); this._exitCode = exitCode;

Related discussion:
text: <!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --The vscode shell integration currently needs to be turned off or disabled for anyone with complex prompt commands, or any trap DEBUG. Please consider supporting some kind of chaining model so we can work with the shell integration as needed. Even better - use the defacto package that has already been written. VSCode is the 3rd script that wants to mess with prompts and traps - but it's the first to completely ignore Please consider shipping this along side and sourcing/using it. If that is unacceptable, consider at least detecting this module has been loaded as documented in the repo - and using it: fwiw: iterm2 has very very similar functionality to the vscode shell integration, but I've been able to work with it. Although they embedded the script directly, they kept the compatible function names and mechanisms and interop fine.
I believe we have already fixed this: Adding to make sure
Well, line 100 breaks my prompt. Adding the line as the 1st line of vscpreexec shows why. I think perhaps there needs to be 1 more state 'not in prompt' that causes preexec to bail until all promptcommand processing is done. Alternatively, if this is all to send vsccommandoutputstart - it seems like using PS0 on bash = 4.4 would be a lot cleaner?
Hi This was on 1.67.2 with dropped in place.
We've made some big changes in the past few days around debug trap and PS1 handling in bash, I believe the issues here are fixed. We may at some point hook into similar to but for now that will just increase the number of cases we would need to test for (contributions very welcome).
Actually I'll keep this open with help wanted to track integrating with bash-preexec.
OK. Pulling the - Things look better, but not quite right. The problems I see (only when DEBUG trap is being used): Still seems to be not preserving $? for promptcommand Seems to execute the trap twice. repro with setup instructions below: Do 'cd' into some directory. The command '..' should then pop one directory up, but it will try to process twice and pop twice.