jiebi/CodeConvo huggingface dataset:
it sounds like you might be using the interactive window which is not what this issue is about. If so, that is
I'm debugging Flutter apps with option which sometimes outputs a lot of lines of logs at once. I suspect that breaks it. When the log density is normal, it works.
How can the fix be tested? Do we need to build from source or is it in the Insiders version?
It went out in the latest stable update. If you're still seeing the issue I can reopen it and investigate a little more
I set up a flutter app and tried debugging it in verbose mode, but it doesn't do anything unusual and I don't see an issue. Also tried some other cases with different types of log messages printed very quickly. are you able to share the app? Or if not, a screen recording of the console, or screenshot of the point where it stops scrolling might help
So, basically wrapped lines considered as single line, therefore it miscalculating how many lines to scroll by?
I'm not seeing an issue with wrapped lines anymore
I'm not sure this is particularly helpful information (besides maybe helping confirm there's still an issue), but I was just able to reproduce this with a Flutter project (on current stable), but have been unable to repro again while recording. It happened while Flutter was doing checks (it prints a lot of very verbose output with all the HTTP requests to the Pub API). I've tried clearing my Pub cache and modifying my pubspec (with so Flutter would re-check Pub packages when the debug session starts), but have been unable to trigger it again (nor could I repro with the original steps using mock-debug above).
Oh, perhaps noteworthy, when it did happen (sorry I didn't take screenshot, I thought it would be easy to repro!), the last few lines printed were a very long line (a large JSON payload) followed by 1 or 2 short (unwrapped) lines.
Issue is still happening. I can't find a good pattern to suspect and reproduce it. All I remember is I had disabled the content wrap setting to give it a shot on my wide screen. Reverting it later did not help. I was doing Flutter development on VSCode for 3 years, and from that day, I'm getting this very annoying bug.
Can you share the project, or the exact log text that causes it so I can try to reproduce it?
I have a fix which I think only affects the case when wordwrap is disabled. From this thread, I'm not sure whether anyone was still seeing an issue with wordwrap enabled. It got a lot easier to repro after my fix for fixed an issue with sizing.
Here's the code I was using to repro the issue: and
I can't repro now, but I saw this again a few days ago, but I do not have wordWrap set, it's on the default (). If I see it again, is there any useful info I can get from it (other than a shareable repro ofc, assuming I can't make one).
<!-- 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.76.0 OS Version: Windows 10 The most recent VS Code update broke bracket colorization for PHP files, when you close a PHP tag then open it again before using a closing bracket. Steps to Reproduce: a PHP file a PHP open tag , open a bracket with , use an end tag , step 2, but with a closed bracket show as red, and the coloured line that joins the brackets doesn't show. Note: The red brackets are normally only used for errors, so it makes it look like there's errors in the file Screenshot: !
Same problem here on Unbutu! Could you fix it please?
Same error on ubuntu Ubuntu 22.04.2 LTS
Also happens if you just have the opening tag but no closing tag at the end: !
Hello, thank you to open this topic. I have the same issue while writing PHP code on VSC. It would be great if could be fixed. Have a nice day !!
Same issue here on Mac OS 13.2.1
Same here
For anyone who needs this fix before the next update: Add this to your settings JSON (fix via PR )
I have a similar issue using math equations in markdown, the image on the left is version 1.76 and the one on the right is 1.75.1, both of them with the same settings (by sharing them). The fix suggested by did not resolve my problem. Should I open a new issue since it is a different language and context? !
open test explorer notice that the input has the wrong background color, e.g it has two background colors <img width="455" alt="Screenshot 2023-11-15 at 14 29 05" src=""
What theme are you using? I can see the slight difference in your screenshot, but inspecting things I'm not seeing any backgrounds being applied to that action / menu bar
Like, any light theme?
Still confused on the latest Insiders for me in e.g. solarized light: <img width="725" alt="image" src=""Does it reproduce on a fresh user-data-dir for you? If so, are you able to do a quick devtools inspect and give a hint as to what styling is being applied that makes monaco input have a different background color?
I see. It doesn't show with an empty profile but I also don't have any setting that screams test explorer background color
Could you bisect your user settings or share them so I can play around?
This seems to be because I have the test explorer in the secondary sidebar. There is some settings that controls this but I have no clue which one it is <img width="2188" alt="Screenshot 2023-12-12 at 18 02 53" src=""
CSS is fun
Testing Ctrl+[RightLeft] Ctrl+Up &mdash; put the cell in edit mode and focused the editor, I expected it to move the focus to the preview cell without changing the selection (like Windows Explorer) Ctrl+Down &mdash; seems to scroll down slowly. Again I expected it to move the focus to the next cell without changing the selection
It seems the ctrl+arrows are already being used by actions.
Meaning expand/collapse headers? Why? If I understand correctly, this is basically what arrow up/down by themselves are already doing, right? ctrl+up/down are matching the editor by scrolling without moving focus. Except that they are double-booked with focus in/out of output, which maybe should only happen when focus is in the editor
I think the only thing to fix here is that ctrl+up invokes when focus is not in the output, and focuses the editor.
Issue Type: <bBug</bSee the , which provides two tasks and and a README with these steps. the task the task again. that each failed in its own terminal, despite what the message in the terminal said. the terminal and press a key to close it. the task . the task again. that both failed in the same terminal, again not shared with the task. closing the terminal, run the task again. that the task reuses the terminal now, but doesn't fail. Instead it just produces no output at all, and doesn't seem to signal that it's finished. The task doesn't hang, it just fails. Its terminal gets reused like the one from . Ideally both tasks would emit the exact same sequence events, including both and so the listener can determine that the task failed. VS Code version: Code - Insiders 1.63.0-insider (, 2021-11-29T08:08:44.056Z) OS version: Linux x64 5.15.4-201.fc35.x8664 Restricted Mode: No <details<summarySystem Info</summary </detailsExtensions disabled<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
or I think the cause of the problem is that doesn't fire when a process task exits with an error like this. I don't think there's anything suspicious in the shell launch configs: ! Would you expect to fire if the process errors out early like this (the command to run doesn't exist)?
When the call to create/start the process fails, like when doesn't exist, it should fire the event here:
It does do that, but it seems that something is still not cleaned up somewhere as process tasks run in a re-used terminal don't output the message at all.
If you have this repro set up could you also log these? This is where the output happens:
In a non-reused terminal: is set to undefined there. is set to the expected message. gets run and gets hit. In a re-used terminal: None of those lines are hit. When I kill the terminal manually they are all hit, but all those values are undefined.
This looks much better than before! However, I still see the task's terminal have an . Is this expected?
Tasks expects the exit code to not be in this case because it indicates that the terminal is being disposed and cannot be reused: Because of this, tasks doesn't keep the terminal around in the task system for re-using, so subsequent tasks will get a new terminal, which is unexpected.
I think undefined for is expected here because a process never launches, instead it fails because the executable is missing before we try to launch the process. This is different to which would run something like and that would exit.
is there a way I can tell on the tasks side if a terminal is being disposed vs. just had the above situation happen? I'd like to reuse it if it's not being disposed so that the user experience is consistent. Just iterate though the and see if the instance with the same ID is still there?
Internally we use to differentiate these: I guess we could just expose that as a type in too, looks like tasks is still the only consumer that uses the value on the event I believe. If you want to try this, change this line: To this or similar:
I'll make the tasks changes in February:
I'm using the on a keybinding to quickly switch between different components in a project. A slightly frustrating behavior is that the window list appears in the same order in both windows. This means that when you do , the first window in the list is always selected. So, if you have 2 windows open and you're switching back and forth between them, you have to remember two key combinations, one for each window you're in: Switching from Window 1 to Window 2: Switching from Window 2 to Window 1: only I propose defaulting the selection to be the first entry that is not the current window. That way, it is a "quick switch" indeed. :) Thoughts? I will implement this when I have time if there is no objection.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.612 --<!-- potentialduplicatescomment --
Don't believe this is a duplicate - the other issues think this unexpected behavior is a bug, while this issue proposes a way to make the behavior closer to what the user expects.
Another way this could work is to by default, select the window after the current window in the window switcher. So you can quickly flip through 3 or more windows.
<!-- 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.82.3 OS Version: Ventura 13.6 This one was tricky to investigate and is impacting the and & scenario. In that scenario, VS Code is started from one application using the macOS command. This reproduces without requiring Unity and with no extension installed. This seems to be a macOS only issue. When opening either from the macOS Finder or through , the VS Code application will expand the PATH of its subprocess so that extensions that depend on something in the path of the terminal will find it. So in my case, if I start VS Code from the Finder, the processes will look like this: This is expected and good. Extensions can find in the PATH. The issue is that now, if I want to open another workspace in the same instance (but launched from another application), the PATH doesn't get expanded in the second workspace and I get: So in my second workspace, will not be found in the PATH.
For this to happen, VS Code must be started from an application launched from the Finder (and not from the Terminal, otherwise it will inherit the PATH of the Terminal) Steps to Reproduce: Xcode, create a new SwiftUI project (I mean, it doesn't have to be a SwiftUI project, you can re-create the issue with anything that is able to output a macOS .app but for this particular repro I used SwiftUI) the Sandbox for the project: <img width="562" alt="Screenshot 2023-10-03 at 10 33 02 AM" src=""the look like this: the variables and to point to 2 different workspaces. the project, I personally use in command line. all VS Code instances. the .app from the Finder, it will be in if you built from the command line by default. the button As you can see from the code, the .app will: set the PATH with a marker open a new VS Code workspace on workspace1 wait a bit open a new VS Code workspace on workspace2 activity monitor, find the child process ID: <img width="1045" alt="Screenshot 2023-10-03 at 10 40 50 AM" src=""the terminal, look at their path: (Your pid may vary) that the second child process doesn't have its PATH expanded, and only inherited the PATH from the .app:
I think you're best equip to handle this issue? but feel free to reassign to whoever.
I can't repro this. To know more, please do the following: Quit VS Code From a Terminal, run , this should open VS Code In that window, run and set it to . Then, from a Terminal, run , this should open the second window On the second window, reveal the Output panel and the Window logs. Search for , what do you find?
the entire point of long repro is to not start VS Code from the terminal, but from an app launched from macOS. As I said in the bug:
Using is the same as launching from Finder. Let me know the result.
I'm afraid it's not exactly the same as it exhibits a different behavior as it appears the second instance of the process will simply inherit the PATH of the process that started it, instead of expanding the PATH to be like a terminal Using twice will work as expected from the Terminal as the second instance of the process will inherit the PATH of the Terminal. Using the repro steps to create an app that will call on Visual Studio Code twice won't work as expected. If I close all VSC instances, and do twice on two different workspaces, I get: Things are visibility different as the main Code process seems to inherits the PATH from the Terminal. Whereas if I launch Code manually from the Finder, I get: So there is a difference.
Thanks for testing! Very interesting, I was unaware of differences here. Last I saw this (when I did the macOS integration years ago), did not propagate environments. It seems like it does now. Can you try just once more with: , replacing with the path to the workspace? Thanks, I really appreciate it!
Version: 1.84.0-insider Commit: With from the Terminal I get the same behavior as :
Hi we're seeing a growing number of customer reports on this. I think I've provided all the info that was needed including a way to create a self-contained repro. How could we get this looked at? Thanks!
Same here guys. Just installed unity + vscode and have this message about missing net sdk. I came from here.
I came here from microsoft/vscode-dotnettools as well – and I'm glad I did! I've been banging my head against the " isn't on the PATH" issue (and related!) for quite a long while and with insight from the fantastic writeup for this issue was able to get it to work again. For me, the break comes down to how I open my Unity project in VS Code. I generally open my Unity Projects is with the following: the project in Unity. "Open C# Project" from the Assets menu. <img width="253" alt="image" src=""If the project isn't already open, Visual Studio Code will open up a new window and load the project. When this happens, I get all the "I can't find !" issues. a new VS Code window (keyboard shortcut/menu/palette/whatever).
the project from within VS Code. In my case, I do this via the "Open Recent..." menu as what I'm looking for is usually listed there. Regardless, if I open the project in VS Code in this manner, everything works as expected.
sorry for the silence here. Let's try to figure this one out. First of all, I can't get your Swift sample to work. It launches VS Code but fails to open each workspace properly, even after triple checking that I've changed both workspace paths to something that exists. I really couldn't figure out why... In any case, can I ask you for one more piece of info? from Finder (main process regular PATH, Code Helper with sourced PATH) a Terminal, call the command with the path to the second workspace. What's the of that second Code Helper process that comes up? Resolved?
Hey thanks for bumping this, happy new year, looking forward to having a resolution for this. That happened to me before I turned the sandbox off. See step 2 of the repro? We could also try the real world scenario with Unity, but it's going to be a slightly longer setup, I'd encourage you to reach out to my email at work to help get you setup. In that case: The main Visual Studio App inherits the PATH of the Finder (so just /usr/bin:/bin) The first process gets a PATH expended. The second process inherits the PATH of the Terminal, verified by doing: Just before calling in the Terminal.
Sorry about that. It runs correctly now! And I can repro! Funny: it seems to only affect the variable. If, say, one adds to , that gets properly propagated to both extension hosts (). Interesting, digging more...
Nice! Good luck :)
Got it!
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified
Issue Type: <bBug The following does not indicate that this is from the universal Mac build: VS Code version: Code - Insiders 1.53.0-insider (, 2021-01-26T05:12:23.287Z) OS version: Darwin x64 19.6.0 Remote OS version: Linux x64 5.4.39-linuxkit <details<summarySystem Info</summary </details<details<summaryExtensions (35)</summaryExtensionVersion ------ unique-lines1.0.0 persona0.0.3 regex0.2.0 vscode-eslint2.1.14 ghlink1.2.0 remotehub0.5.0 tsl-problem-matcher0.3.1 EditorConfig0.16.4 vscode-npm-script0.3.13 codespaces0.6.0 vscode-pull-request-github0.22.0 vscode-mocha-test-adapter2.9.1 vscode-test-explorer2.19.5 rest-client0.24.4 graphql-for-vscode1.15.3 template-string-converter0.4.7 git-graph1.28.0 vscode-azureappservice0.20.0 vscode-docker1.9.1 vscode-kubernetes-tools1.2.3 remote-containers0.156.0 remote-ssh0.63.0 remote-ssh-edit0.63.0 remote-wsl0.53.1 azure-account0.9.4 azurecli0.5.0 hexeditor1.3.0 vscode-github-issue-notebooks0.0.60 debugger-for-chrome4.12.11 vscode-versionlens1.0.9 vscode-yaml0.14.0 music-time2.1.0 vscode-open-in-github1.14.0 vscodeintellicode1.2.10 vscode-test-resolver0.0.1 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
To verify. check if the universal apps version information in about dialog as well as issue reporter details have it like <img width="564" alt="Screen Shot 2021-01-27 at 8 32 54 PM" src="https://user-"
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: OS Version: Steps to Reproduce: Relatively niche but: refactor menu (action widget) over a disabled action either arrow keys or typing filter to select an item. that the disabled action becomes highlighted !
Type: <bBug</bI use the shell: When I start VS Code not from the terminal, I see a popup with the error: I know why this issue occurs - it's because VS Code is assuming bash semantics for launching the user's shell in order to solicit environment variables. I encountered the . In that report, I reached out to the xonsh project (xonsh/xonsh) to see if the shell might be able to support bash syntax for this purpose, but after some consideration, they rejected the idea, instead asking editors to honor the shell. Here I'm making the same request to VS Code, namely that if the shell is xonsh ("xonsh" appears in the user's shell path), to use a syntax specialized for xonsh to extract the user's environment, namely: If direct support for xonsh can't be , would you consider adding a configuration variable such that a user of xonsh could customize VS Code to honor xonsh as the default shell? VS Code version: Code 1.85.0 (Universal) (, 2023-12-06T18:18:04.614Z) OS version: Darwin arm64 23.1.0 Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (7)</summaryExtensionVersion ------ copilot1.141.0 copilot-chat0.11.0 black-formatter2023.6.0 isort2023.10.1 python2023.22.0 vscode-pylance2023.11.10 sublime-keybindings4.0.10 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I acknowledge that starting VSCode from the CLI does work around the issue, but even then only for that launch. If I launch VS Code from the CLI, then it has to restart (such as due to an update), it once again is unable to resolve settings and the error appears.
I believe this is or ?
<!-- -96bd-47a8-a0e8- --This feature request is now a candidate for our backlog. The community has 60 days to the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our . Happy Coding!
This is a backlog candidate but still PRs are welcome. Here's where explicit xonsh support would need to be :
this is being in with minimal testing, could you track any comments/issues with it while I'm out in January? We mainly just need author verification
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected. If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Verified by installing and starting insiders from the terminal. I didn't see the error mentioned above. would be good if you'd confirm this.
I can confirm, with 1.86.0-insider, the error is gone. I was unable to test on the original machine, but I've tested on a new, similarly configured machine (and confirmed that the default shell is configured for xonsh, same as reported above). I'm so delighted that it's fixed and that I was able to help. Thanks for the guidance and support. /verified