jiebi/CodeConvo huggingface dataset:
<!-- 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.67.0 OS Version: Windows 10, using as a default shell Steps to Reproduce: When debugging python(I think debuggers of other languages also got effected too), I'm using following to redirect stdin to my custom input file. This method of implementing redirection when debugging using the < character is also introduced in the . According to the document, This approach requires that the "<" syntax is passed through the debugger extension and ends up unmodified in the Integrated Terminal. and it worked like charm before updating to . From , I've noticed that there was a fix related to automatically add escape character() before special symbols such as or (See Terminal on Windows uses cmd /C, this corrupts passed arguments) When I started debugging session, vscode is now really add before . Since character is escaped, I cannot used redirection with the method mentioned in the document anymore. Is this the intended result? If so, how to use redirection 'correctly' after this build? I know a lot of people redirect stdin to and redirect stdout to when debugging, which is actually very convenient. I think that implementing redirection by passing special characters(, , ) as arguments of the debugger is not a very graceful solution, but that method itself should not be eliminated.
Having the same issue with new version in WSL. It seem some characters are prefix with . My is . But in console, the command is , due to prefix , my code is stuck. It was working fine yesterday, So, I think this issue is with new release.
VS Code Version: 1.67.0 OS Version: Windows 10, WSL Ubuntu20.04
Judjung from of , I'm sure this issue is related to today's release too.
Yeah this is Thanks for pointing out the docs, I didn't know this was recommended. It's suspicious to me that we would want to put shell-specific syntax in the args here. That isn't what "args" means to me. I wonder whether we could add launch config parameters like "stdinFromFile" and "stdoutToFile" (and add those to the runInTerminal request) so that vscode can come up with the right syntax for the shell. I may want to revert the change until we have a better solution. Thoughts Maybe candidate
I'm not a fan of allowing this. We already try to escape things from those arguments, so people doing this today have only a half-working shell syntax in their arguments. It also only works if you run it in the , and is of course shell-dependent too, which feels weird.
This is super messed up. I 100% require being able to redirect the output. This needs to be fixed. ages: ["",""] was 100% working on windows before this update! My work flow is screwed rn
Args mean arguments as if I was writing it after typing it in console including SHELL commands. I want to redirect output Why in the world it would add ^is crazy to me. This has to be be bug.
Additional sometimes you need to chain aliases that take redirect or pass a redirect back in < These are shell scripts that having the debugger "args" accept <,,| is really important to have. It was an amazing and highly convenient way to debug. I seriously doubt this is a feature that few people would want deprecated. I seriously don't and it's killing me it broke after this update.
Yeah I agree that passing redirection symbols through args is somewhat weird, and I understand the need for escaping shell-specific characters. That's why I've said it's not a graceful solution. However, many people uses the redirection feature through that way now(even if the docs have been mislead the users). It's good improvement to escape that characters in arguments since it is literally "argument", but I think there should be official solution to redirect I/O.
As mentioned above, add parameters such as "stdinFromFile" and "stdoutToFile" to might be best solution. BTW, what kind of additional information do I have to add here? I think I mentioned all the details of the sitution but I see the "needs more info" label.
I've spent 3 hours trying to come up with a work around. This is insane. So much of my workflow relied on the ability the redirect stdin and stdout using <,. It's insane that this was deprecated. I don't even get why. It doesn't have to do any crazy checking should just copying what you type in and the shell takes over. This is a serious issue for me. !
If it's about "escaping shell-specific characters" then I could live with this. And if it's about anything else shell then give me something like this:
Sorry for the trouble. Like I said, I didn't realize that people were depending on this behavior, and I agree that it should be supported somehow, since this is a reasonable and useful workflow. To me, "args" means arguments that get passed to the program you are starting. I see a couple solutions Restore the behavior of and require users to shell-escape args in their own config, which is not good, or add which would be shell-escaped Keep the behavior of and add or , or the more specific Any of this will require changes to DAP. I wonder whether anyone is trying to use any shell syntax besides /<, in other words, is there a scenario that adding wouldn't cover?
In my opinion, the second way Keep the behavior of and add or , or the more specific is better workaround since we can prevent use of different way from its real meaning.
just a few comments from vacation... VS Code knows nothing about properties. Some debug extensions introduce in their schema contribution but VS Code cannot provide any direct help with redirecting input/output. VS Code supports/implements the DAP request which some debug extensions use to implement their (private) support. does not allow direct access to shell features (e.g. input/output redirection) because no assumptions can be made about the underlying shell or whether a shell is used at all. So escaping/quoting all shell meta-characters is correct. But we might want to add additional features to the DAP request so that debug adapters can implement / property support themselves.
a debug extension can introduce an alternative property that supports shell features, e.g. a property . In order to support this we would have to add support to the DAP request to pass a full command line unchanged to the underlying shell.
is there a scenario that adding stdinFromFile/ stdoutToFile wouldn't cover? Yes. I for one will use aliases that are shell scrips to redirect their input and output to chain together programs.
Yes, this is basically my thinking. But I think I should revert the change as a candidate until we figure out a better solution. could you give me an example so I understand how that wouldn't be covered by this proposal?
"stdinFromFile/stdoutToFile" makes the most sense to me. I would not be in favor of a option in the request since, similar to the initial problem, the DA has no knowledge of the underlying shell.
I wonder whether we could make everyone happy in the meantime by leaving the current fix but special-casing and and not escaping these? You could have the and filename in a single arg but I don't see anyone doing that. And it would make the behavior almost the same as the intended escaping behavior.
If would work with "" instead of "", "" I could live with that. Or what ever you mean by special-casing. I just want it to work again or have some means to do to it again.
I mean the opposite (the in would not be escaped, and in would be escaped)
that seems like an acceptable interim fix to me. As a C++ debug extension author (vGDB), this has also broken my extension on the most recent VSCode build and I've had to suggest users defer on upgrading for now to not break existing workflows.
Thanks. I am going with this solution for the .2 build that will go out next week. Not a perfect fix - as a single argument would have previously redirected output too - but people are using or in all the examples I have seen so far. It will also be in Insiders tomorrow. I noticed another issue with the escaping, , which will also get fixed in Insiders
thanks for the quick fix!
Type: <bBug</bI got the following error randomly while changing workspace settings. I used the extension bisect feature to see if it was an extension, but nothing was identified on the very first pass. The issue continued to persist, until Visual Studio Code was reloaded. Here's the message that appeared in the problem pane: Problems loading reference 'vscode://schemas/settings/workspace': Unable to load schema from 'vscode://schemas/settings/workspace': cannot open vscode://schemas/settings/workspace. Detail: Unable to resolve text model content for resource vscode://schemas/settings/workspace. I found a similar issue regarding multi-root workspaces on github: My workspace has multiple folders. I only edited the workspace settings and I never touched the folder settings for the workspace. I did made some recent adjustments by installing/uninstalling extensions, switching profiles, and editing workspace settings. VS Code version: Code - Insiders 1.77.0-insider (, 2023-03-14T05:23:49.668Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<details<summaryExtensions (11)</summaryExtensionVersion ------ Ionide-fsharp7.5.1 csharp1.25.4 dotnet-interactive-vscode1.0. vscode-dotnet-pack1.0.12 python2023.4.1 vscode-pylance2023.3.20 jupyter2023.3. jupyter-keymap1.1.0 jupyter-renderers1.0.15 vscode-jupyter-cell-tags0.1.6 vscode-jupyter-slideshow0.1.5 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This is probably caused by of the schema (and others) It would be better to register the schema immediately but empty, and to set it later again with content.
Can this be at least workarounded somehow? It's very irritating - I cant edit any workspace settings
I'm sure a hotfix will release the fix to all of us soon, but here's a workaround for now: I found that poking any settings key in restores proper autocomplete/hover in VSCode's until next VSCode restart. But a key must be poked after every restart.
For example, put at the top of your and save the file. You will have to toggle and save this key every time you start VSCode. A detailed set of steps for doing this can be inspected at the end of this comment. If you use the VSCode extension , you can set up a hotfix keybind (like in this case), and press the keybind twice every time you restart VSCode. Or, just never restart VSCode until the patch drops! <details<summarydetails</summary<pI can confirm that setting allows hover hints and completion to function again, e.g. in VSCode's own modification. However, this workaround throws out all JSON linting and reporting in the "Problems" pane, so it's sort of the nuclear option. This issue just cropped up for me in the past few days, so it may be a regression associated with the latest release? After further investigation, I find that poking any settings key in restores proper autocomplete/hover in VSCode's until next VSCode restart. But a key must be poked after every restart. Here's a rundown: all tree of settings keys are initially at their defaults, e.g. none of these keys are explicitly specified in any of your (maybe unnecessary, but this is my starting state). VSCode (e.g. with ). Navigate to your user . The following warning presents in the Problems pane: a trivial setting modification in the tree of settings keys, even if that modification is a no-op, like explicitly specifying a default as its default value. For example, put at the top of your and save the file. (You could've also poked to be either or I think, maybe?) whether autocomplete/hover works properly in , completing settings names and such. It should work now. can even remove the edit you made in step (4), save again, and autocomplete/hover still works. VSCode. autocomplete/hover is broken again in , until some modification to the tree of settings keys is made again, like in step 4. For example, commenting out if it's there, and saving, restores autocomplete/hover.
So this issue may have to do with unstable startup behavior of JSON schema handling, perhaps isolated to VSCode's own or perhaps all JSON schemas more broadly, and this unstable state can be temporarily fixed by poking a settings key, but the unstable behavior returns on the next program start. At least in my case. </p</details
I have encountered a similar error: So nothing I do in my file has any effect. Not only that, but when I type "" into the Settings search bar, the only thing that comes up is a reference to a file under .
In my case I think I found the culprit: The property above gives a "Value is not accepted" error even though it's a valid value that works when the is enabled (it's currently disabled). As soon as I delete this property, the "Unable to load schema" error goes away. Weird. Update: I spoke too soon -- after reloading VS Code, the "Unable to load schema" error is back
A few days/restarts later, and the error is gone. Looks like a Heisenbug.
For me the problem message appears in a typescript node project when I have open. Close this file and the problem message goes away. (The file contains no known issues). While others report either user or workspace settings reference loading problems, for me it is configurationDefaults:
is there any update on it? it's very frustrating and I don't see a reliable workaround
<!-- 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!
I still see this <img width="1619" alt="image" src=""Repro: a syntax error in , which will result in some setting's value being "changed" that forces restart of vscode dialog to restart vscode shows up, click on "Restart" restarted vscode will likely have this error
I cannot reproduce this, are you seeing this consistently?
I can't repro deterministically, but I feel like it has to do with loading/reloading the window
Can others subscribed to this issue, please try our latest insiders and let us know if you still see the issue?
/verified
I confirm this is fixed in (tested under Ubuntu 22), and without the need for .
I just upgraded to the regular version and it also seems to be fixed there as expected ^^.
Can U confirm it is now fixed in version 1.80.0 and close the issue ?
The message is still there for me in 1.80.0.
Thanks for confirmation. I will close this as fixed and verified. Please reopen a new issue if you are still seeing it (may be new) with steps to repro.
For me the message showed up in 1.80.0
For me too
Currently experiencing this issue. I can overcome it temporarily following a suggestion elsewhere where I add or remove "": true to my file. I keep adjusting the file to see if there is something in there ausing the issue. Even old, known settings are causing the error to kick in regularly. I put a single setting in there and the error comes up unless it's empty Version: 1.80.0 (user setup) Commit: Date: 2023-07-04T15:06:02.407Z (1 wk ago) Electron: 22.3.14 ElectronBuildId: Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0.
Currently experiencing the issue on my linux machine. On my Windows machine (with the same configuration file, since it's synchronized) it works fine on stable, but not on insiders. Can confirm that toggling as a workaround works until restart.
Linux version: Version: 1.80.0 Commit: Date: 2023-07-04T13:39:48.236Z (1 wk ago) Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.80.0 Chrome/108.0.5359.215 Electron/22.3.14 Safari/537.36 Windows version (stable): Version: 1.80.0 Commit: Date: 2023-07-04T15:06:02.407Z (1 wk ago) Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.80.0 Chrome/108.0.5359.215 Electron/22.3.14 Safari/537.36 Windows version (insiders): Version: 1.81.0-insider Commit: Date: 2023-07-13T05:33:32.822Z (2 hrs ago) Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Code-Insiders/1.81.0-insider Chrome/108.0.5359.215 Electron/22.3.14 Safari/537.36
Reopening this because it can be still reproduced.
I am getting this error and I can't figure out how to fix it.
Please try our and see if you are still seeing it
Currently seeing this while in a file on GitHub Codespaces, in the following form:
Can you please try insiders and see if you are still seeing this?
I still saw this issue when opening on: Version: 1.80.1 (user setup) Commit: Date: 2023-07-12T17:22:07.651Z Electron: 22.3.14 ElectronBuildId: Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0.
As I mentioned, this was in GitHub Codespaces. I can't change the version of VS Code they serve to the browser.
Type: <bBug</bVSCode, create a folder named, for instance, "XXXX". that folder create another called .vscode .vscode create a file named with this content: VSCode sure the setting "task.allowAutomaticTasks" is not set or is set to its defautl value "auto". "XXXX" with VSCode. VSCode will run "echo Hello" without asking you whether you want to run tasks configured with "runOn": "folderOpen" or not. VS Code version: Code 1.70.2 (, 2022-08-16T05:35:13.448Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
This happens because you have presumably opened a trusted workspace - which is now when we allow these to be run if the setting is "auto" for allow automatic task
The described behavior is how it is expected to work. If you disagree, please explain what is expected and what is not in more detail. See also our . Happy Coding!
! If I understood it correctly, the popup that supposedly asks you whether you want to run these tasks is not actually meant to appear ever because if the workspace is trusted it will be executed without asking you and if it is not trusted then it will just not exeute them instead of asking you. Doesn't it look kinda pointless to have in the description of the option of the configuration "Prompt for permission for each folder"? You are never prompted anyways.
I this configuration and I am still not prompted anyways:
No I did not. Please next time ask the user if he did X before assuming it and closing the issue. I tried reproducing the problem with and without a trusted workspace and the problem persists anyways.
i'll investigate this that shouldn't happen
Tasks will only run in trusted workspaces, so I will update the setting description to indicate that. Also need to fix the prompt not happening per folder.
Type: <bBug</bSince the upgrade to 1.91.1, the tooltips/popups (that show function documentation on mouseover, for example) have become a hinder, because they seem to get sticky, being in the way when I want to select/click something on the lines that the tooltip/popup is overlaying. I'm not 100% sure how to explain this, or what exactly changed, but I know this wasn't a problem in the version before. Something definitely changed in version 1.91.1. I'm not sure if it's because they're appearing faster, or taking longer to disappear, or... Thank you! VS Code version: Code 1.91.1 (, 2024-07-09T22:06:49.809Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (13)</summaryExtensionVersion ------ better-comments3.0.2 vscode-intelephense-client1.10.4 path-intellisense2.9.0 vscode-eslint3.0.10 gitlens15.2.0 prettier-vscode10.4.0 duplicate1.0.2 vscode-github-actions0.26.3 php-cs-fixer0.3.13 vscode-phpunit3.2.2 vscodeintellicode1.3.1 php-sniffer1.3.0 php-debug1.34.0 </details<!-- generated by issue reporter --
Hi the editor hover has not been fundamentally changed last iteration. Last iteration I have refactored the editor hover code so this could be the source of the new issue you are seeing. For me to understand better the situation, next time you see the issue you described, could you post a screen recording here and an example of the code where you are seeing the issue?
Thank you. I cannot show much of the code, but here's a short video which I hope helps. (I tried to "exaggerate/force" a bit, but it should show what I mean) These editor hovers have been annoying me all day, since the update. They just keep being in the way. In previous versions, wasn't the hover disappearing when the mouse leaves the tooltip? Or when the user is selecting text? Thanks.
[video removed, for privacy]
What version were you previously on?
Hi the hover should still disappear if you keep your mouse outside of the hover for long enough. Perhaps you could change the value of the setting . This setting controls how quickly the hover disappears. The default is 300 ms, meaning that after 300 ms outside of the hover it disappears. Similarly you could tweak the setting - this setting controls how quickly the hover shows, ie how long the cursor needs to be on a word before the hover is shown.
I believe I was on 1.91.0, but maybe I didn't use it enough between upgrading to that one, and 1.91.1, to find this issue. Before that, I was on last month's iteration, which definitely didn't have this problem. Thank you. I was going to change that option, and then I saw a hint about having to be enabled. So, what I did is I actually disabled that one. Seems to have improved a bit. It seems to be still remaining sticky if I do put the mouse over it, so I'm not sure what exactly that option does (its description says the hover will remain visible when mouse is moved over it), but somehow, disabling this option makes the hover disappear if I move the mouse outside the code that triggered the hover, which is similar to the behavior I had before, I think. And if I click on the hover, it remains sticky, which is good/expected. Great. I changed from 300 to 600, so it doesn't appear so quickly. Thank you for the tips. I think there's still one question left -- what about when I'm selecting text (like shown in the video above) ? Wasn't the hover supposed to disappear, once I'm selecting text, and therefore the user is not interested in having a hover in the way of the selection? :) Many thanks, again!
Hi thank you for the comment. I believe the way the editor hover works is that when you click outside of the hover, the hover disappears. Meaning when you start a selection it disappears. However as you move the cursor to expand the selection and hover on a word the hover can appear again. Perhaps we could make the hover never appear when a selection is under way, I will open an issue about it and let the community put votes on it.