jiebi/CodeConvo huggingface dataset:
There does appear to be a pretty serious bug in that code: It adds to the at line 1839, then starts the task at line 1853, and then removes at line 1855 without waiting for the task to finish. So in practice the list is almost always empty, and doesn't actually do anything. I think the at line 1855 should actually be in a clause attached to the on line 1856, so that it doesn't run until the task completes. But fixing that doesn't actually fix this issue, because the set isn't preserved (or reconstructed) across reloads. In addition it breaks the above behavior where trying to run an already running task asks what you want to do with it (because now that inProgressTasks is actually working, it aborts the attempt to re-run the task before it gets to the point where that dialog is presented). It also breaks tasks that are explicitly marked as allowing more than one instance. So since it isn't currently doing anything, and fixing it breaks things, I would suggest removing all the associated code ( I'm not sure what the actual fix should be though. There seems to be code to try to reconnect tasks to terminals: but it doesn't seem to work (I've stepped through the code with my example, and it goes into but doesn't actually find any tasks to reconnect). So maybe the bug is there. Or maybe the bug is that the tasks shouldn't be preserved across reload (many are not; a terminal that isn't running anything will be killed by reload, for example). But I've reached the limits of what I can debug, unless anyone has suggestions for where to look.
thanks for looking into this. the reason it's not in a is this was meant to (and did) fix an issue that was super hard to reproduce where duplicate tasks would get started. the only tasks that get reconnected to are those with and have problem matchers. you can disable this with .
task reconnection works for me https://user-
Ok. So there's a race that happens between deciding to launch the task and actually launching it? In that case, the solution seems kind of misleading. Shouldn't it be something like rather than ? but also, instead of why not just do And why do you need the in since it was already deleted right after it launched?
But all this is incidental; I was hoping this code could prevent the bug I reported, but clearly it can't.
Ok... but the problem is that my task is left running across the reload, but it doesn't get reconnected (apparently intentionally), so attempting to start it again succeeds, even though it's supposed to only allow one instance. https://user- I'm not sure what that .mov is supposed to be showing me; I can't see anything relating to tasks being reconnected (but I'm not sure what Im looking for). But anyway, I'm not claiming it's broken; just that it doesn't reconnect my task (or similar ones). And if, as you say, thats intentional, then the bug is elsewhere. But as far as I can tell, either my task shouldn't be left running, or it should be reconnected.
Another data point. After reloading, the task is clearly running, but tells me "No running tasks"
So when I set this to false, my task is killed on window reload, which does mitigate the problem (in fact, for my use case, I think this does solve the problem - although I don't know yet whether it introduces new ones). But that still leaves us with the issue when is . The task is left running, but not (properly) reconnected - so although it's there, and its output is going to.a terminal, the abstractTaskService, and terminalTaskSystem aren't aware of it (so that "Show Running Tasks" says there are none, and attempting to start a second instance succeeds).
I won't be looking into this any time soon just fyi. So if it bothers you, feel free to keep digging. Otherwise, just keep the setting disabled.
I run into this problem all the time too, which is very frustrating. I have to reload often due to SSH reconnection etc, this reattach issue together with ssh agent forwarding on mac os breaking, are really detrimental to the work flow. Using works around some of the issue, but exposes a new one; one of my processes doesn't get killed and blocks the new one from starting. That process appears to be a nodemon process, perhaps related to
Yeah that is unrelated to this feature as you mentioned.
as noted in the pull request, this doesn't fix everything, but it makes my workflow (with several auto-run tasks) much cleaner.
Those tasks will be properly reconnected on reload, rather than an additional set being kicked off on each reload. For tasks that don't auto-run on reload, the only change is that the first attempt to run a new instance of that task will simply attach to the existing process; and subsequent attempts will fail the same way they do before the reload. Other than that, there should be no change in behavior, so I think this should be pretty safe. I spent some time trying to figure out how to actually reconnect all the running tasks, rather than just marking them for reconnection, but I kept running into issues where needed to know about the internals of ( in particular). Or I needed to extend the ITaskSystem api - which I'm reluctant to do without guidance. I also tried a completely different approach - namely, including non-background tasks in . That almost worked, but the problem was that gave a different result when the task is launched manually vs when it's run from (when run manually, its a , but when run from its a , which gets resolved to a ). As a result, the tasks did get reconnected properly, the various commands (eg ) know they're there and do the right thing; but now trying to run them manually uses a different key, and still starts a new copy...
thanks for looking into this. I commented on your PR
To verify, run a non background task. Reload the window. Verify that you can run that task again
<!-- 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.88.0-insider OS Version: Darwin arm64 23.2.0 Steps to Reproduce: folder text View as Tree View as Tree ! View as List ! Mysteriously, some of them do show up when run in a project with many folders...
Did not reproduce in
Same for me: Version: 1.88.0-insider (user setup) Commit: Date: 2024-02-29T22:51:22.369Z Electron: 28.2.2 ElectronBuildId: Chromium: 120.0.6099.276 18.18.2 V8: 12.0.267.19-electron.0 OS: Windows_NT x64 10.0.
Also for non-tree view it doesn't show the single result: 3 results shown: ! 1 result isn't shown: !
watching :
There is no way to set aiResultsVisible and it always returns false now. The hasDownstreamNonAIResults called here should also only contain NonAIResults, so it is false and should not be in the if statement, but it is now. Upon deeper investigation, we found that it occurs under the following conditions. It seems that the deepest part of the TREE is not displayed in this way. This is because the folderMatchesIterator is retrieved, but the deepest point is always [] and [].some() =false. You also need to look into fileMatches iterators.
Apologies for the inconvenience, and thanks for finding the fix!
Issue Type: <bBug</bFold a region and observe it. Unfortunately this went away after a window reload: VS Code version: Code - Insiders 1.66.0-insider (, 2022-03-23T05:27:08.615Z) OS version: Darwin arm64 21.4.0 Restricted Mode: No <!-- generated by issue reporter --
There haven't been any changes from mein that area recently. Likely a Chromium glitch. Please reopen if you have it reproducible.
I still don't know why this happens sometimes, but it shows up regularly. In the dev tools it shows that chromium has loaded the stylesheet in a wrongly encoded way. I hope to avoid this by escaping the ellipses unicode character.
<!-- 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.92.0 Commit: Date: 2024-07-31T23:26:45.634Z Electron: 30.1.2 ElectronBuildId: Chromium: 124.0.6367.243 20.14.0 V8: 12.4.254.20-electron.0 OS: Linux x64 6.9.3--generic Steps to Reproduce: theme to Light High Contrast a Javascript file final bracket is black, not red as in other themes
I believe this may be the core cause: The value for hcLight here is just an empty string
Thanks for investigating, looks like this color got forgotten when creating the Light HC theme. I took the same color as used in the overview ruler
with the remote repositories and codespaces extensions installed the remote explorer on under prompt (see ) escape to close and cancel Bug A url is still opened Version: 1.68.0-insider Commit: User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X ) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.64 Safari/537.36 Embedder: <!-- generated by web issue reporter --
I'm not seeing the section that Matt describes in the linked issue. !
The remote explorer is in the sidebar: !
When I disable the "Show raw keys" option (showKeys) in the VS Code settings, the editor no longer shows the shortcuts either. If the "showKeybingings" option is enabled it should show the shortcuts. This is not behaving the way expected. !
When I set these settings: <img width="652" alt="image" src=""I still see the command if I hit . You don't see it?
Unfortunately it doesn't work for me in this same configuration. Version: 1.85.1 Commit: Date: 2023-12-13T09:47:11.635Z Electron: 25.9.7 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: Linux x64 6.5.0-14-generic
I found something strange. Some commands works fine, like "Ctrl + N", "Ctrl + P", "Ctrl + Shit + P", "Ctrl + Tab". But it still doesn't work with commands like: "Ctrl + C", "Ctrl + V", "Ctrl + A", "Ctrl + X", "Alt + Arrows", "Ctrl + Arrows". Could you please test the commands when editing code?
Sadly this is this: A big chunk of our internal commands simply do not have good descriptions. It requires a large change over the code base. Feel free to send a PR my way which adds descriptions to the few that you are dependent on, if this is important.
Ok, but I would like it to show commands such as "Ctrl + C" even without a description and that is not happening. If I set it to show only the commands it continues to behave the same way, without showing the commands in the editor part. I remember that when I sent the commit that fixed some problems in the screencast, it was working perfectly, but now it no longer works. ! It still doesn't work in this configuration.
You simply closed the issue and didn't even understand the problem I brought up. I see that these are two different problems. This is very frustrating...
You're right, sorry for jumping the gun there, and thanks for the additional explanation. Fix coming.
<!-- 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?: It requires at least the remote SSH extension to be enabled due to the nature of the bug, all other extensions can be disabled/uninstalled. <!-- 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.75.0 OS Version: Local Windows 10 21H2 / Remote Fedora 29 Steps to Reproduce: -up VS Code with Remote SSH Python Extension in to Remote SSH error message and get asked to download manually opens link: the following error text: it's because the extension hasn't been published for 2023.2.0 for Linux yet so try installing older version same error and browser instead opens this link: very similar error text: I have had to revert to 1.74.3 where I am not getting this error so can I continue to work, but if you need me to test things again I can install 1.75.0 again and retest.
I am having the same issue since upgrading to VSCode 1.75.0. When trying to update the Python extension on the remote server I get an with the log Trying to download manually brings me to the as reported above. I am getting the same errors for the Jupyter extension. I could successfully update the extensions locally. VSCode: 1.75.0 OS: local openSUSE Tumbleweed / remote Red Hat Enterprise Linux 8.5 (Ootpa)
I have the same problem.
Same issue. Downgraded VSCode to 1.74.3 to restore functionality.
VS Code Version: 1.75.0 OS Version: Local: macOS Monterey 12.6.3 Remote: Amazon Linux 2 w/ Kernel 5.4
Triaging this issue I am unsure if the initial post with the error message of is the same as the error with the message . Therefore all conversation on the issue should be moved to this other issue: Thanks
This issue is related to target platform and not related to sign verification.
Yes, I am initial poster, I also get the signature untrusted error. I assumed the two errors had the same underlying cause, i.e. when VS Code made the web request it got the above error which does not have the signature of the extension and therefore throws a red herring of "Untrusted: Signature", then when VS Code prompts you to download it manually you can see the actual underlying error. This is why I posted the latter error and not the former error. But if you are convinced they are two separate errors then it makes sense to track them separately. But be aware I got both errors, and everyone else who has posted seems to have also got both errors.
Thanks for the info It seems that the root cause is signature error for you too. Being said that the manual download shall work. Can you please share the link you are using to download the VSIX?
From the marketplace web page. Version History -2023.3. -Download Manual download and install work for me.
As per my original post the link that VS Code to manually download the extension is: Which gives this error:
It seems VS Code is generating an invalid download link. Updating this issue for fixing the update link. For signing related, please refer to
I'm not sure how to get this, are there repro steps?
To verify Open extensions view Browse for eslint extension (any non platform specific extension) Disable network connection Click on install, you shall see a prompt to Download Manually Enable network connection and click on that Download Manually button Make sure the VSIX is downloaded/
Moving this over from After the backups are not restored if the workspace directory doesn't exist anymore. The workspace is no longer tracked but the backups are kept around in the backup directory should they be needed later.
Tricky.... I would expect an empty window to open with those files dirty. This might require some work on the area of restoring on empty workspaces. Have not thought about this longer yet.
Marking as important because this means data loss if the folder is deleted on disk.
maybe this should be done on the main side on startup similarly to If a folder no longer exists, convert it into an empty workspace backup and let it open as empty window.
On test plan:
Testing scenario in Codespaces web UI Opening a Python file in a fresh codespace Web UI shows a notification: ! Clicking on Yes shows ! VSCode desktop is opened Python calls VSCode should intercept that URI and handle it by directly opening the extensions viewlet and not make an external call
Unassigning myself as it seems url handling related. Please let me know if there is something I have to do in extensions area.
What do you think? Should we perform the fast-track to handle these URIs internally?
I can't repro this in desktop Code. I can repro in web
I couldn't get the Python extension to show that dialog again, so I verified that with my own extension that does That code is inspired by That code works and, on codespaces now directly opens the extension viewlet. -verified However, if you do '();' it opens the external open dialog again. In the first case the URL has a relative path (), in the second one an absolute (). Relative paths are kind of rare. Is that all as designed? Or would it be better to also accept the absolute path?
Paths are not required to be rooted in , or even separated by characters: they can be arbitrary strings within the allowed character set. We've long defined extension URIs to simply be . Not sure if you've seen the format anywhere in our docs? If so we gotta fix it.
I will have to revert the fix for this, since it broke existing functionality. With the fix, a web extension can no longer actually open a URI in desktop Code. When looking at the breakage, I no longer this this is true. If is invoked, it should always be handled externally, never internally, unless it's absolutely obvious (running in Desktop). The right way to move forward here is to have the Python extension run the instead of calling .
VSCode Version: 1.37.1 OS Version: Linux x64 5.1.14--generic Steps to Reproduce: a search term (make sure it actually exists in the current document) the replace term empty the match case box Ctrl-Alt-T the error ! Does this issue occur when all extensions are disabled?: Yes
What does do here? I don't think I have that keybinding.
I think I meant Ctrl+Alt+Enter, the shortcut for replacing all. I am not sure if it is the correct shortcut (I don't have access to my laptop right now), but it is not specific to it. I am guessing replace or replace all will trigger the same bug.
I can't reproduce it. It would help if you can try it again and get the full error stack from the developer tools (Help Toggle Developer Tools)
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
The "Open in Terminal" does nothing when the current window has no folders. Instead, if there are no folders, it should open a Terminal window in the same directory as the current file.
this works for me, how are you running "Open in Terminal" exactly?
I'm using while I have a saved file focused in VSC. !
That command opens the active workspace folder currently. Maybe we should fallback to the active file if there is no folder open? Open to PRs
I would like to work on this as my first bug. Could I get some advice on how I should go about fixing this?
Great! All the external terminal code is located in the "execution" part You change will be in here: Utilizing the (see for how to pull it into that file).
Type: <bBug</bo meu terminal do vscode ficou todo preto derrepente, ele esta normal e quando fui abri-lo estava preto, nao consigo resolver e nao posso voltar a minha rotina por causa disso. My vscode terminal suddenly went all black, is that normal and when I opened it was black, I can't resolve it and I can't get back to my routine because of this. ! VS Code version: Code 1.81.1 (, 2023-08-09T22:22:42.175Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (8)</summaryExtensionVersion ------ turbo-console-log2.9.6 gitlens14.2.1 auto-rename-tag0.1.10 copilot1.105.350 prettify-json0.0.3 vscode-language-pack-pt-BR1.81. vscode-thunder-client2.10.5 vscode-icons12.5.0 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Please write the pn in english.
/duplicate
can you share your file?
here it is
Confirmed that is disabled by default. I have now enabled terminal gpu acceleration and images, though I'm not sure whether I'll run into the issue on this machine.
<!-- 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.