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:mac os monterey 12.3.1 Steps to Reproduce: to settings (command+,) for markdown drop <img width="719" alt="Screen Shot 2022-05-20 at 11 55 58 AM" src="https://user-"
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.67.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Confirmed on latest insiders Version: 1.68.0-insider Commit: Date: 2022-05-16T05:30:27.563Z Electron: 17.4.3 Chromium: 98.0.4758.141 16.13.0 V8: 9.8.177.13-electron.0 OS: Darwin arm64 21.4.0 <img width="636" alt="Screen Shot 2022-05-20 at 1 11 00 PM" src="https://user-"
Fixed as of
<img width="967" alt="image" src="https://user-"
Hey I see with the same fixes, already merged.
Yeah but it accidentally got reverted via This just brings your changes back in
<!-- 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. --<!-- 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: version 1.76 OS Version: Windows 22H2 Steps to Reproduce: a debugging session, and click on the "Edit Condition..." button (the pencil). Ensure that the cursor is in a window with a short width. ! appears. ! window. The text appears to be cut off. ! to look like this: !
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.76.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Probably we need to relayout that breakpoint editor when the parent editor width changes
I'll get it done
My phone is not working unless connected to wifi I need serious help as I am to be in GA at 7am I realize this phone is outdated a Motorola it is used but my Apple I cannot see the screen on it and I obviously can't carry my pro on the road cuz it is not activated can someone help me you can record everything l do not care I need help
All kids are grown? The Samsung used to belong to my son now belongs to coworker On Sun, Apr 9, 2023, 8:29 PM Amy Scarbrough
Running Extensions context menu -in extensions have disabled menu for !
I don't remember creating the "Report Issue" action, so I don't think I own it. Maybe you did this?
Yeah I did this. Code pointer The issue here is that the JavaScript Debugger does not seem to provide the repository URI in the Thus the action gets disabled here can you maybe provide the repository information of the JavaScript debugger so this button gets enabled here?
There are multiple built-in extensions with disabled menu item, like, , , ... (Not only js debugger).
Yeah none of them have a seperate repository. So you shuold just file in vscode repository However for js-debug we have a sepearte repository so it makes sense to have that action enabled.
I have an repository in the js-debug I think the issue is actually the line above that exclude built-in extensions: I don't think this line is necessary. Deleting it will just have people who open issues on extensions in the vscode repo open them here, which is desirable.
Yeah, agree.
Report Issue on opens this repository . Some other built-in extensions still have disabled menu item.
This action is available only for few builtin extensions (jsdebug, emmet) and this action reports issues in VS Code repository. IMO it shall be consistent and show this action for all builtin extensions. If repo is not found and extension is builtin we shall enable the action and create issue in VS Code repo. Let me know if you agree, if so shall I reopen this issue?
Works for me and let's reopen. I am opening this for community contributions and adding help wanted
I think there are two ways to do it. attributes need to be to the of each built-in extension In the , judge the extension type. If it is a built-in extension, set the base url to I think 2 is better
Yeah let's go with 2. Sounds like a good approach to me
I have submitted a PR, please help CR
thanks to your PR this is now fixed.
Fixed for built-in extensions, though just a note that it's still disabled for the github.codespaces extension.
<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.34.0-insider OS Version: All Steps to Reproduce: This issue is difficult to reproduce as it requires a special version of an icon theme extension that supports theme reloading ().
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.592 --- <!-- score: 0.528 --- <!-- score: 0.482 --- <!-- score: 0.45 --<!-- potentialduplicatescomment --
Being a maintainer of the extension, I stumbled on this issue while testing the implementation of this feature on our extension. As I'm the author of the theme reloading feature, I pinpointed the cause of the bug. The reason for it is that on we don't call the event, resulting in the not getting notified. The solution is to add a call to on the function. Although much of the code execution of the is overkill when we reload the icon theme, it has no side effects. Possible actions are: and extract the calls to telemetry and event triggering to separate function and then use only the extracted function nothing and just add the call to and don't care about the redundant code execution since it does not have any side effects. I'm more than willing to provide a PR according to the chosen action, although I suspect that you guys prefer action 2. Awaiting your response.
I like the suggestion of calling . PR is of course very welcome!
<!-- 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. -- (merged as ) and other colors relating to the foreground of icons in the activity bar when it is configured to be at the top of the sidebar. I'd like colors for the activity bar background when it is at the top. Specifically, I'd like these new colors: to set the background of inactive icons and the region of the top activity bar not occupied by icons, corresponding to . to set the background of the active icon in the top activity bar, corresponding to . See also , .
<!-- -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!
! vscode 1.86 Windown 10
We two new color. One for the activity bar background when it is set to the top / bottom () and one for the border between the activity bar when set to top / bottom and the views ()
Added
Verification steps: activity bar location to the top the following colors in of your file and see the color change in the activity bar at the top : Background of the activity bar : Border color between activity bar and the view container : Background color of active activity item
Thank you very much for your efforts! What needs to be is: Can you add the following color setting items: ! This color setting project has been a long time coming, but no one has ever made it happen.
Can you create a separate issue for this? These are colors that we don't yet have for the default activity bar, right? In that case, please also include a very short description for each color in the issue.
No need at the moment, thank you very much!
Due to how colors are blending together. Notice the color of the input and the selection of quick open and how the black background blends into the viewlet, so the input looks misaligned. <img width="1035" alt="screen shot 2017-06-27 at 15 23 22" src="https://user-"
Hello, I'd like to help with this! UPDATE: I believe I've fixed the issue by changing the "" property in the monokai theme from "" to "". Before the change: ! After the change: ! Shall I submit a pull request? Thank you!
Yes, a PR would be great!
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.78.0 OS Version: Windows 10 (x64) Steps to Reproduce: "Centered Layout". the editor by independently moving its sashes (holding down Alt). and restart VS Code. The position used to be remembered in previous versions, but starting with version 1.76, the position gets reset on every start. Only the width is being remembered. It's still broken in the current insider build of VS Code 1.78.0.
Do we already know, which commit causes this regression?
I looked through the commits for 1.76.0 and I suspect it was .
Yeah, it is solved for me.
I am forming an openEditorAtIndex command using the following syntax: '' + index 1-9 work correctly (and are default keybindings already). Would it be possible to add support for any index? I currently need to use this command if <= 9 and if 9, I have to go to index 9 and then next count - 9 times to get to the desired pane with a risk of wrapping around
trying to understand the scenario here, I do not think it makes sense for VSCode to introduce commands for more indices because this number is pretty much unlimited. Can we have another command that just goes to the next index, from the current one and you could use that instead? E.g. does it work if you use ?
Lines 55 - 89 are what I use to be able to go to any tab My case here is what I am trying to avoid Ideally I could do and never think twice about it The problem with using nextEditorInGroup is that I have no way of knowing the max editor number index, so if I say go to tab 10 and there are only 8 tabs, the current logic will try to go to tab 9 with the absolute exposed command, then use a nextEditorInGroup command.
that switch-case statement looks quite horrible, an alternative would be for the workbench to expose a command where you just pass the index as argument into. We already have that for other commands, e.g. see the "move editor command" () Would that be better?
That would work for me too! It is not very urgent since I don't think people navigate to tabs they can't see very often but for completeness it would be nice! Thanks!
Great. I would accept a reasonable small PR on this feature request.
I'll try to write a reasonable small PR for this :)
landed, thanks to
Some steps so I do not have to read the whole discussion? What command with what arguments should do what now?
here you go: write an extension that executes and verify the tab at that index opens.
Works nicely. Though the counting starts from - might be a bit confusing.
Ah yeah good point, but I think that is fine.
<!-- 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.63.2 OS Version: macOS 12.1 (ARM64) I can't get more than two launch configurations to run at the same time. I can run the rest of the configurations afterwards and everything works (debugging, etc.). StopAll will also only close the two configs that were successfully launched. I haven't found any mention in the documentation that this is limited to two launch configurations. I've only seen that two are used in every explanation or tutorial about this feature. Steps to Reproduce: multiple launch configurations in multi-root workspace inside of project roots. launch configurations to compounds in .code-workspace file debugging two of the many compound configurations will run Examples:
VS Code imposes no limit on number of launch configurations in compound config. I've verified this with this simple example project (which only relies on built-in VS Code features and not third-party extensions): unpack zip file in VS Code use "Open Workspace from file" to open workspace file inside folder switch to debug viewlet in debug config dropdown select and run "4 Debug Session" Observe: 4 debug sessions: <img width="1384" alt="CleanShot 2022-01-26 at 11 45 23 src="https://user-"Maybe there is a limit on dotnet/coreclr?
Thank you for taking a look at this After inspecting your configuration and some research in my own project I was able to isolate the culprit. The problem arises when you try to make use of inputs in the launch configuration.
I created a demo for download, the process is the same as you described above.
thanks for the additional info. I was able to create an even smaller repro without a multi-folder workspace: unpack zip file in VS Code open the "compound" folder switch to debug viewlet in debug config dropdown select and run "Compound" Observe: only one debug session starts
Is it possible to implement the input that allows blocking another input request until the first input has completed? Latter quick pick also cancels former ones so it needs to be fixed as well.
Do you own the configuration resolver Is my solution correct or should the service guarantee correct behavior when calling into it multiple times simultaneously?
your solution looks good. The configuration resolver service doesn't currently make any guarantees about what will happen if it's called into multiple time simultaneously. I would also be fine with the change being in the configuration resolver service though. We can change it's behavior so that it does make that guarantee.
Yes, making the fix in the configuration resolver service sounds better.
This fix doesn't fully cover our scenario (tested in latest insiders). This fixes case, and yet we also prompt for input or quick pick in , which is not covered in this PR. Is it appropriate to wait for as well?
Good point. Yeah, I think that makes sense.
I guess we'll need Queue's for and Would you like to make the changes, or should I work on this?
I can take care of it
This gets a bit weird. Since one launch config can be calling into the variable resolver (the first fix) while the second is calling the extension config provider, we also need a queue that orchestrates those two things. Easiest fix is to start launch configs one at a time instead of kicking them off in parallel: and I'm not sure what other impacts that could have. Perf to some extent, probably. So I wonder whether we would ever consider queueing calls into the quick pick control so that invoking the quick pick while it is already visible would wait instead of cancelling the first one as it does currently. Example of what I'm talking about (but in my real situation it's an extension competing with code in core): This extension code only shows one input box, while we could have the second wait for the first to complete. This could possibly be a breaking change for some extensions though, so it could be enabled with a flag.
As an easy workaround, I can put a queue around calling into the vscode variable resolver and calling an extension debug config provider. But, putting a queue around two unrelated pieces of code seems to say that I'm solving the problem at the wrong level.
Or maybe make them the same level by moving the resolve queue to
Just to be clear. The two callers of the are in two different places right (core and extension)?
Right
Ok I've not heard of any feature request like this but feel free to open one... I wonder if maybe instead Core could have concept of "important" quick picks that can't be stomped over by extensions and instead the extension calls wait until Core is done. Then we don't need any more API
It can also go the other way. The problem is just that there are two async processes that have to run and show a quick input, and we need both of them to complete and not to get canceled by the other. Filed I'll go with a workaround for now, so I'm not blocked, just figured I'd start the discussion
Sorry for the late reply. I tested this today and it works for our scenario. Thanks for the quick fixes!
Issue Type: <bBug</bThe description for is copied from VS Code version: Code 1.64.2 (, 2022-02-09T22:02:28.252Z) OS version: Windows_NT x64 10.0. Restricted Mode: No Remote OS version: Linux x64 5.4.0-100-generic <details<summaryExtensions (15)</summaryExtensionVersion ------ jupyter-keymap1.0.0 remote-ssh0.74.0 remote-ssh-edit0.74.0 vscode-icons11.10.0 gitlens11.7.0 cmake-language-support-vscode0.0.4 git-graph1.30.0 vscode-dotnet-runtime1.5.0 python2022.0. vscode-pylance2022.2.3 jupyter2022.1. jupyter-keymap1.0.0 jupyter-renderers1.0.6 cmake-tools1.9.2 cpptools1.8.4 </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
in VS Code stable and VS Code insiders all cells in each quickly up and down through the notebook :bug: in VS Code insiders scrolling over notebook outputs is not smooth anymore; scrolling appears to stutter and halt over notebook outputs I took performance profiles in stable and insiders but devtools won't let me save them unfortunately. Nothing stood out though in terms of memory usage or a particular function call increasing in percentage across profiles. LMK if I can provide more info
Is this with a trackpad? I might be seeing this. Could be a regression from
I've the same issue with a trackpad on Windows.
Yeah, trackpad on Windows for me as well
Variable substitutions that are available for (see ) do not include currently selected text. I am looking for something similar to $(CurText) that is available in Visual Studio Arguments for External Tools (see ). Please add a variable ${curtext} which would be replaced with the currently selected text in the editor window. If no selection is available, it could use the current line at cursor position.
Nice idea, but I think it's too late for implement that in the current milestone...
Fixed by in
Verifiers: what happens if all text in a 300 MB file is selected...
good point. Maybe we should put a limit on this. Or only to copy the howl line at most (even though the line could also be 300mb I am fine with that) thoughts?
Selecting lots of text, at some point I get . If there's a predictable limit where this will fail, we should just cut the string off there. Unless only sending part of the text could be dangerous or unexpected for the user. In any case I think that sending multiple lines of text could be useful.
there is not a predictable limit since the variables are used in different scenarios. If somebody has an idea for a limit I am open to PRs
Issue Type: <bBug</bPlotting a large plot (e.g seaborn pairplot) with many columns via jupyter interactive mode and then viewing in plots viewer is very slow to view/zoom/pan VS Code version: Code 1.45.1 (, 2020-05-14T08:27:35.169Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </details<details<summaryExtensions (11)</summaryExtensionVersion ------ vscode-django0.20.0 vscode-markdownlint0.36.1 python-extension-pack1.6.0 gc-excelviewer2.1.35 r1.4.2 vsc-python-indent1.10.1 MagicPython1.1.0 anaconda-extension-pack1.0.1 python2020.6. vscode-yaml0.8.0 vscodeintellicode1.2.8 </details<!-- generated by issue reporter --
This sounds like a problem caused by the extension providing the Jupyter Notebooks. Please file the issue there.
Hi same problem here, are there any workarounds in place for this?
I've moved to
<!-- 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?: 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: 1.77.1 OS Version: All Steps to Reproduce: This is not a problem in the extension, the extension code is the same, but a commit changes the way webviews are loaded and it's breaking it. This commit: Has introduced a regression that makes my extension unusable. It introduces a problem on webviews in which workers are not available, and causes the following errors in the console: Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'active') at I have been tracking all changes since 1.76.2 release, building VSCode myself, and setting the build to the previous commit, my webview works flawlessly, if I checkout this commit, it's totally broken. I have not been able to send you are reproducible test case, but if interested, I can show you a video on how to use my extension, so you can check for yourself the issue. Thanks!
To add more information, check these two videos: Not working scenario, with the code at 1.77.1: ! Working scenario at the commit previous to the one I mention. Just remark that checking out the code at the commit I'm pointing, causes the not working scenario: !
Sorry you are running into this. Do you have an extension you can share that shows this issue? I can't simply revert the change because it was made to fix an hang with webviews opening. If I can repo this locally though, I can try to investigate
Thanks for checking this one!