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 (all other extensions disabled) <!-- 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. --- Version: 1.89.0 Commit: Date: 2024-05-01T02:09:22.859Z Electron: 28.2.8 ElectronBuildId: Chromium: 120.0.6099.291 18.18.2 V8: 12.0.267.19-electron.0 OS: Windows_NT x64 10.0. This is a continuation of I'm in the process of creating a product icon theme and noticed the following icons not being (properly) replaced. They either appear invisible or are unthemed. There may be more icons that suffer from the same problems described below, but I have not been able to find them as of writing this. The icon is invisible after applying the theme. This is due to the following CSS rule overriding the attribute: ! Same as settings editor tab icon, it's invisible for the same CSS rule overriding the attribute. Visible in, for example, output and terminal panel views (left next to close icon), editor tabs more actions (where the 'split editor' action icons is), etc. This doesn't appear to get any overrides at all, so it remains unthemed. The icon is invisible after applying the theme. This is due to the a second attribute always being present and overriding the first attribute that correctly retrieves which value should have. !
To verify: extends the with export it as VSIX, import select the theme verify that the settings editor has now a explorer icon, as well the more icons
<!-- 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: OS Version: MacOS Big Sur latest Steps to Reproduce: Create a new profile Click on the Profile Activity Bar icon, then choose Result: the quick pick comes up... ! Now click on the menu item to bring up the view Click on the menu item again Result: focus just moves to the pane ! Expectation: Show the Quick Pick so the menu works the same regardless of whether or not the content view is open
I was also hit by this - that by clicking on "Export Profile..." it looks like it has no effect, when it fact it just passed the focus. we could always show quick pick as Chris suggests?
What about the contents view when you click on again? Does this has to be closed or remain like this? May I understand what is confusing in navigating to the contents view when you click on export profile button?
I think you can leave the view open, but I would open the Quick Pick right away, not force the user to click on the Export button (again).
Another idea (that was also mentioned in the UX call) is how about always open the view and ditch quick pick? This was initial flow actually.
I think that flow might work. My biggest concern is that users might not notice that the focus moved to the view (especially if the view is already open). Long term - maybe the view becomes a custom editor? fyi
Quick pick is removed and by default we show the contents view now.
VSCode Version: 1.7.2 () OS Version: Windows 10.0. Steps to Reproduce: a file a sentence of text such as Lorem ipsum sit dolar amet. your keyboard cursor after <kbdTab</kbdExpected: Spaces or tabs to be between and Result: word gets converted into an XML tag and auto closed, leaving us with <Lorem</Loremipsum sit dolar amet. !
This is coming from Emmet. To disable this, add: to your settings. Although this is currently the expected behavior, I think we should probably disable emmet expansions in markdown by default because this behavior can be annoying during normal writing. Any thoughts?
this behaviour is a consequence of , which has as the goal to not hard code in which language modes emmet is enabled for. As a heuristic uses the grammar's scope name hierarchy as a hint. This heuristic has worked pretty well. The scope of the markdown grammar is . This means Markdown is treated as a specialization of and since emmets supports , is enabled in Markdown as well. According the emmet doc there is no special syntax profile available for Markdown So a quick fix would be to: hard code an exclusion for markdown in #isEmmetEnableMode change the scope name of the markdown grammar, so that it doesn't inherit from html, not sure what the consequences of this are. do you have other ideas how to improve the support for emmet in Markdown and avoid the surprise described in this issue?
Hello, I see the same way as you suggested above. But, perhaps, we can also disable Markdown in the settings, as it was for . If you decide to disable Emmet inside Markdown, it is better to first option. But my 2 cents: Markdown is a lightweight markup language and it presupposes the existence of HTML constructs within yourself. Thus, it seems to me, to disable Emmet inside Markdown is not correct. P.S. Small news: the creator of Emmet had already started work on the second version aka 2.0.0
thanks for the feedback. I agree with your point that disabling emmet without some way to re-enable it, if someone really wants emmet is better than to totally disable it. Glad to hear about Emmet 2.0.
Could just be in the default setting for ?
That would stop most users from triggering emmet unexpectedly in markdown files, while still allowing users to opt back in to emmet for markdown if they wish
the idea is good. It has a small drawback. If someone defines in the settings, then they will not profit from this fix. However, if someone if familiar with this setting and then they know how to disable emmet in markdown, if they are annoyed by it. Bottom line I'm fine with this fix.
Ok, I've merged in which adds to the default list of excluded languages. Not a perfect solution, but it should stop many users from hitting this behavior unexpectedly
Type: <bBug</bCopilot and auto inline suggestion. , type the following comment in the first line and hit enter: soon as you hit enter to change a line, you will hear an audio cue and alert for the inline suggestion, such as . Press alt+F2 to see if you can open Accessible View. Notes: Accessible View is not open. VS Code version: Code - Insiders 1.83.0-insider (, 2023-09-28T05:34:00.540Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (92)</summaryExtensionVersion ------ android-dev-ext1.3.2 aiprm-lang0.0.2 Bookmarks13.4.1 openscad1.2.1 spellright3.0.118 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 vscode-markdownlint0.52.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.25.0 gitlens14.3.0 EditorConfig0.16.4 prettier-vscode10.1.0 vscode-google-translate1.4.13 codespaces1.15.4 copilot1.117.446 copilot-chat0.8.
remotehub0.60.0 vscode-github-actions0.26.2 vscode-pull-request-github0.72.0 overleaf-workshop0.2.4 cslpreview0.2.2 easy-snippet0.6.3 path-autocomplete1.25.0 latex-workshop9.14.0 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 vscode-bard0.0.10 google-search0.0.1 vscode-lua-format1.3.8 lilypond-formatter0.2.3 lilypond-pdf-preview0.2.8 lilypond-snippets0.1.1 vslilypond1.7.3 zotero0.1.10 git-graph1.30.0 vscode-docker1.26.1 black-formatter2023.4.1 flake82023.6.0 isort2023.11. python2023.16.0 vscode-pylance2023.9.20 jupyter2023.8.
jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.313.0 remote-ssh0.106.4 remote-ssh-edit0.86.0 remote-wsl0.81.5 vscode-remote-extensionpack0.24.0 azure-repos0.36.0 cmake-tools1.15.31 cpptools1.17.5 cpptools-extension-pack1.3.0 js-debug-nightly2023.9.2717 powershell2023.6.0 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.130 vscode-selfhost-test-provider0.3.18 vscode-serial-monitor0.10.0 vsliveshare1.0.5883 autodocstring0.6.1 pandocciter0.10.3 shiny-python0.1.4 shinyuieditor0.5.0 quarto1.100.0 r-debugger0.5.4 java1.22.1 vscode-xml0.26.1 r2.8.1 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.7.0 latex-utilities0.4.10 cmake0.0.17 errorlens3.14.0 intellicode-api-usage-examples0.2.8 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.54.0 vscode-java-dependency0.23.1 vscode-java-pack0.25.14 vscode-java-test0.40.0 vscode-maven0.42.0 markdown-all-in-one3.5.1 grammarly0.22.1 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
I see that's happening because the model says there's no content for that line. I notice that it goes into this cache and returns . Any idea what we can do about this? ! !
here's where is returned
this is a breaking issue for screen reader users. Any thoughts would be appreciated.
Issue Type: <bBug</bGitHub reported a security vulnerability related to the NPM package in my VS Code extension's . <img width="765" alt="Screen Shot 2019-06-18 at 5 49 45 PM" src="https://user-"In my VS Code extension's , I've a dependency for : When I run to see what packages are using , I see this: <img width="156" alt="Screen Shot 2019-06-18 at 5 49 23 PM" src="https://user-"And I see this reflected in my : VS Code version: Code 1.35.1 (, 2019-06-12T14:29:22.216Z) OS version: Darwin x64 18.6.0 <details<summarySystem Info</summary </details<details<summaryExtensions (15)</summaryExtensionVersion ------ vscode-css-formatter1.0.1 npm-intellisense1.3.0 path-intellisense1.4.2 bracket-pair-colorizer1.0.61 vscode-eslint1.9.0 gitlens9.8.2 vscode-npm-script0.3.7 auto-rename-tag0.1.0 beautify1.5.0 ibm-streams0.5.0 vscode-duplicate1.2.1 java0.46.0 change-case1.0.0 JavaScriptSnippets1.7.2 ReactSnippets2.3.0 </details<!-- generated by issue reporter --
Seems NPM org is taken by someone :( I'm now forking mocha to update to fix security alert Wondering what I should do :one: Publish it under :two: Make depends on octref/mocha on GitHub :three: We should create a NPM org for these kind of packages What do you think?
can't we just update to mocha 5 or 6 in the vscode module?
will talk to you in chat
Ah, I thought Mocha 5/6 would have breaking changes so we can't really upgrade easily. Turns out Mocha 5 only had : Drop IE9/10 support. It shouldn't affect us. Meanwhile if someone really needs Mocha 4. He can use and manually depends on it. Will upgrade to Mocha 5.
Thanks
Issue Type: <bBug</bthe refactoring window over any element with many available refactoring options (e.g.: a widget in Flutter) tab selection won't move BUT if you hit enter it will choose an option other than the highlighted one VS Code version: Code 1.33.1 (, 2019-04-11T08:27:14.102Z) OS version: WindowsNT x64 10.0. <details<summarySystem Info</summary </detailsExtensions disabled <!-- generated by issue reporter --
Assigning because this only happens when using custom title bars. Repo Windows with custom title bar enabled the ts file: code actions and press tab once or twice, then enter The second or third code action ends up being applied even though the visible selection never changes
Issue Type: Bug folder ! VS Code version: Code - Insiders 1.21.0-insider (, 2018-02-21T09:22:14.399Z) OS version: Windows_NT x64 10.0. Reproduces without extensions <!-- generated by issue reporter --
Code pointer
does it mean that this is the expected behavior?
I m on it.
it is always debatable if something is a feature-request or a bug. I guess this is more of a bug, but I took the artistic freedom and assigned feature-request.
it does not seem to restore the full expansion state, only the first level is that true?
yes, only the first level. could improve the PR and try to restore more.
Yes, i can do that.
great, tree should have api to get the exapnsion state. And once the pr is ready just ping me on it.
Should i make a new method to return all the expanded children as array on treeModel?
Is this ready for verification?
ben already verified and can add a verified label. There are some limitation which will tackle in a pr for next milestone
<!-- 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: Version: 1.84.0-insider (user setup) Commit: Date: 2023-10-23T05:34:05.496Z Electron: 25.9.1 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: Windows_NT x64 10.0. Steps to Reproduce: two workspaces a couple of files Active Editor into a New Window on the new window and Press Alt+F4 : aux window closes. Actual: VS Code closes the workspace and both windows associated with it.
Can you see if is assigned as keybinding? I assume this goes through our global window close handler that has not yet adopted aux windows.
I have default keybindings { "key": "alt+f4", "command": "" },
To load local resources (for example ones bundled with an extension), the  method must be used. As far as I can tell, when a URI produced in this way is requested by a webview, VSCode serves it via something like a local webserver. But there is no way to configure the MIME type that the URI gets served with. This request is to add a way to set the MIME type. This is important for extensions which want to load WebAssembly resources in the webview. The most efficient method to do so is , but this only works if the WASM blob is served as . So currently it doesn't seem possible to load WASM in a webview in this way. Since fallback methods may fail to cache WASM compilation results, I've measured that for a large WASM blob it's actually more efficient to load it from the internet via , as then subsequent loads reuse WASM compilation results, than it is to load it from a local resource.
/verified
When I run all tests, the label resets back to after all tests were run. This is very confusing. !
This was a result of a bad filter function that caused all test runs to be treated extension-triggered. The "real" test run would then never have results, or get any output. More importantly, this results in "show test output" usually showing nothing. Taking this as a candidate. Essentially the sequence is: is triggered from the UI, so we prepare TestResults for incoming data and send the TestRunRequest precursor over to the EH EH doesn't associate that request with the existing run calls from its , which gets treated as a brand new run, so we make new TestResults for that run run and states get updated... 's resolves automatically marks the UI-triggered run as complete since the runHandler returned and there are no ongoing TestRuns latest completed TestResults is now the empty one that core created and was never updated so things that use the last result, like "show test output", are empty The code path in is meant to only be taken by the new Continuous Test runs, where the request is long-lived and doesn't have a single associated set of TestResults.
Type: <bBug</bThis issue was supposed to be fixed in , but we have recently received complaints from some users regarding this. I counted the first 50 issues with Vue extension installed in , and 25 users are using 1.8.27 ~ 2.0.10 (2.0.10 was released 4 months ago ), only 19 users are using the latest version (2.0.22 ~ 2.0.28). Numbers: 2.0.10: 13 (Issue , Issue , Issue , Issue , Issue , Issue , Issue , Issue , Issue , Issue , Issue , Issue , Issue ) 2.0.8: 6 (Issue , Issue , Issue , Issue , Issue , Issue ) 2.0.7: 2 (Issue , Issue ) 2.0.6: 2 (Issue , Issue ) 1.8.27: 2 (Issue , Issue ) 2.0.22~2.0.28: 19 Since some versions in 2.0.0~2.0.10 may have serious problems, this is probably the reason why the Vue extension has continued to receive negative reviews on the Marketplace and VSCode has continued to receive bug reports about the Vue extension for several months. I found a Windows computer with 2.0.7 installed and was able to reproduce the issue of not being able to update the version. The following is the content of . (Formatted for easier reading) And I can reproduce the problem of not being able to update by overwriting the above metadata to the file of another macbook. is installed, uninstall it and then close VSCode and reopen it. 2.0.7 from https://open- and install it to VSCode, VSCode can normally prompt that Vue extension needs to be updated. and modify the metadata of the last extension to: VSCode will find that the Vue extension cannot detect newer versions. VS Code version: Code 1.92.1 (, 2024-08-07T20:16:39.455Z) OS version: Darwin arm64 23.1.0 Modes: <!-- generated by issue reporter --
cc
I just checked our telemetry for the most popular combinations of VS Code version and Vue extension version and here's what I see.
This proves that vue version and are indeed not getting properly updated. The root cause of this is the fact the vue extension, unpublished from the Marketplace and published again the same name (thus exposing a bug in the Marketplace) as explained here We still want to help transition your users, and I will go ahead and move this issue to the VS Code repo and Sandeep will investigate next week once he is back from vacation. Thank you !
Update is not detected automatically. It is detected only when user is searching for the extension.
Sorry about this inconvenience caused. Fixed it - We will now detect the update automatically.
<!-- 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 just tested it and confirmed it's fixed in the latest insiders version, thanks a lot!
Adding label based on above comment
VSCode Version: Version: 1.67.0-insider (Universal) Commit: Date: 2022-04-06T05:15:27.397Z (8 hrs ago) Local OS Version: macOs 12.3.1 / arm Remote OS Version: Centos 7 Remote Extension/Connection Type: SSH Logs: Steps to Reproduce: SSH Session the popup, hey Python and Jupyter extensions have pre-release versions or install / switch to pre-release on the extension page Error (but the extensions shows the pre-release state), but afaik that's not the case Note: I removed the vs code server on the remote host and did a new installation (starting from locally with the remote extensions versions), but it actually just installs the stable version on the remote and then the switch is not possible. It should actually consider and install the same version that is used locally, shouldn't it? Can't install pre-release version of 'ms-toolsai.jupyter' extension because it is not compatible with the current version of Visual Studio Code - Insiders (version 1.67.0-insider). Does this issue occur when you try this locally?: No Does this issue occur when you try this locally and all extensions are disabled?:No logs: [2022-04-06 15:51:45.599] [renderer1] [info] Downloading the 'ms-toolsai.jupyter' extension locally and install [2022-04-06 15:51:45.626] [renderer1] [error] Can't install pre-release version of 'ms-toolsai.jupyter' extension because it is not compatible with the current version of Visual Studio Code - Insiders (version 1.67.0-insider).: IncompatiblePreRelease: Can't install pre-release version of 'ms-toolsai.jupyter' extension because it is not compatible with the current version of Visual Studio Code - Insiders (version 1.67.0-insider).
at l.checkAndGetCompatible (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-) at async l.downloadAndInstall (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-) at async l.installFromGallery (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-) at async (index 0) at async Object.j [as settled] (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-) at async Ms.installFromGallery (vscode-file://vscode-app/Applications/Visual%20Studio%20Code%20-)
Would you mind sharing your Remote SSH logs as well? And if you have any gifs or videos of what you're seeing?
! ! And this - but it's just a "refresh" problem, once I switch between extensions it shows the old and unfortunately correct version again: ! And logs...
Your SSH connection looks successful. I'll transfer this issue to the Python extension team to see if they have ideas why this state is happening
This is an error thrown by VS Code, not sure what an extension can do about this as installing extensions is completely managed by VS Code. I'm transferring this back to VS Code.
Same issue happends to me.
I was able to install this manually (remote) by downloading the new extension that I got from this link: By this, you'll switch to the pre-release version. After installing it once manually, all updates work as usual.
Can you please try our latest insiders and see if you can reproduce this issue still?
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
Sorry, I had it already solved and thought it wouldn't occur again + I moved away from using Remote SSH whenever I could. I am now on the latest 1.68 insiders and for whatever reason the jupyter extension reverted to "non pre-release" and the same issue still exists - same error. Same workaround as above fixed the issue for me.
Were you using any remote set up when this happened again? Are you still able to repro it?
Yeah, it's exactly the same setup, just updated (yesterday's) insider build.