jiebi/CodeConvo huggingface dataset:
similar to the 'open in data viewer' command from the jupyter variables view, we should allow extensions to contribute a view for a variables for specific language/types on the built in tree view.
That would essentially be number 6 in this screenshot from the Julia extension , right?
Same idea, either with an icon like that or through the context menu on that item. In the jupyter extension's case, we are planning to allow contributions for data viewers from extensions that didn't necessarily provide the variables.
Cool. I think icon and context menu would be great ;) It might also make sense to think a bit ahead there: there are probably some kind of viewers that are relevant for a lot of languages (tabular data, plots) and others that are very language specific. From our end, we would love it if VS Code at some point gained a generic tabular viewer, and a plot viewer that we could utilize and get rid of our custom implementations as well :) So maybe some kind of API design where in the future one could hook into a as of yet not existing generic tabular/plot viewer.
Example implementation here The menu contribution point name will likely change names when we expand the usage beyond notebooks, but any needed migration will be pretty straight forward.
I created a sample extension and cannot see any variables showing up. Do I need to enable something in VS Code for this feature to work. I couldn't find any settings/experiments that had to be enabled for this.
Found that I needed to enable a VS Code experiment (I was looking for Jupyter experiments). Not sure the API is useful in its current form. Currently when i create a viewer for DataFrames, lists, objects, anything I do not get the name of the variable. Hence I have no idea what I'm looking at, all I get is a value, and thats basically a stringified version of the value. Thus its not really possible to create any viewer, unless of course I'm missing something here.
Moving to March for now. Feel free to move back to February if the issue has been verified or once steps are provided and the issue is verifiable in the latest Insiders. Edit: I confirmed using the sample extension that the viewer does not report the variable name.
<!-- 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: Stable & Insiders OS Version: Any Steps to Reproduce: Jupyter extension the following cell against a Python kernel The expected output is fairly simple: ( can appear some where in the middle) However VS Codes output is incorrect We are missing the line breaks (looks like this PR seems to have broken that) (using blockinline-block` fixes this). We have duplicate entries (as you can see below, we have multiple times) i think this has to do with the fact that we're trying to re-use the previous output and append the new stuff into the previous output element Note: This can be repro'ed in stable as well, but if i were to remove the code that tries to append to the previous element, then it looks as expected. Not sure when this part of the code broken though. Didn't go through the change log to determine this, you might have a better idea.
note that this is from the test, so that could probably be modified to check for the fix
It looks like this was briefly solved (at least for me as I reported in ) but the problem is now reappearing.
I agree, I can replicate the same bug again, hence reopening this issue. Looks like subsequent change regressed the fix.
seems to be a worse regression now (only in insiders) and repros without needing to do anything with background threads (unless I just have some bad setting): !
I'm seeing something similar with the JavaScript/tslab notebook I use for teaching async and promises. Previously, the output was inconsistent across runs with sometimes missing or duplicated output.
Now all the expected output is present but with line breaks appearing only after some async code (e.g. ) is executed. <img width="661" alt="image" src="https://user-"
I reproduced output shown by above with missing new lines in code-insiders at ~14:00 UTC +1 (CET). In a code-insiders session that has been running last 24 hours. Restarting code-insiders approximately an hour later (15.00 UTC+1), the output is now shown with correct line breaks, see screenshot below. Version: 1.75.0-insider (user setup) Commit: Date: 2023-01-09T05:29:27.679Z Electron: 19.1.8 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes Output after code-insiders restart: !
confirmed that this no longer seems to reproduce on the latest.
Adding label as confirmed above.
From ! It took me a while to be able to use Copilot again. Here are the steps I took (also captured in the attached video): Reloaded VS Code Clicked "Show Extension" from the toast above, I'm brought to Copilot Chat extension in Extensions view Clicked "Uninstall" for Chat extension, nothing would happen Decided to instead search Copilot in Extensions view (thought maybe I was having issues by trying to uninstall Chat without touching Completions, though I would've expected a toast telling me that) After searching, the Copilot extensions automatically start to update Need to restart just Copilot (not chat), so I click to restart I try to uninstall Copilot Chat again, but nothing happens again Reload VS Code again Search for Copilot again in the Extensions view I can now uninstall Copilot (though I initiated the uninstall from the Copilot extension rather than Chat)
Verification steps are in
PR introduced a max-height on comments, which goes against my team's use case when using the . Since our tours have animated GIFs that support our hands-on coding labs, the reduced max-height makes it impossible for a user to see entire images in the comment frame at once, which imposes a negative learner experience. (See: for comparison across versions). Proposed feature is to allow a user to set a max-height rather than imposing a max-height.
I also think it should be settable through the API. My original on the PR has a comment exchange with about this at the place where I originally hardwired it.
Generally we try not to add API unless we see a clear case for having it. At the time suggested the max height I wasn't aware of a use case that would require a comment peek view to have a larger size. your case makes sense, and makes the case for having API for this. I would make this API rather than user configurable.
Yes, making the max-height configurable via the API makes perfect sense, since any extension can be configured with that functionality to set a max-height attribute that makes sense for the use case. Would the default behavior go back to expanding the height with the content?
I'm not sure yet which would be default. I will discuss with our UX folks and see what they prefer.
My humble preference would be to adopt the old behavior as the default. Though the CodeTour extension is open source, it’s only seen one update in the past year. My team has a stale PR from 2021 on the CodeTour repo that was never commented on, so I’m afraid that even if we opened a PR with a fix for the max-height problem, it might not ever get accepted and merged. On the other hand, my team has been discussing forking CodeTour so that we can control the addition of new functionality and bug fixes.
There wasn't enough interest in adding API for this, so I the user setting .
thanks! Is a boolean? If so, is the default (maintaining the as by default) or (no defined?
It is a boolean and the default is true, meaning the max height of a comment will be 20em.
<!-- 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.
<!-- 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.72.2 OS Version: Windows 11 / MacOS Monterey Steps to Reproduce: . the icons using the command. that the arrows are still not hidden. The vscode-icons extension has a setting called , which, as the name suggests, hides the explorer arrows next to the project folders. This look something like this: ! With the introduction of the tree mode in the search panel, I would not have expected to see any explorer arrows there. Alas, the panel has the search arrows, regardless of the extension setting. ! I already opened an issue on the vscode-icons repository, which you can find .
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.72.2. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
Still happens on 1.72.2!
<!-- 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, this is an extension-related issue that arises across extensions with walkthroughs <!-- 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.91.1 OS Version: Windows 11 Extension walkthroughs are not launching upon install. Expected behavior: walkthrough launches automatically upon install. Tested on C# Dev Kit extension and Python extension. Seemed to work in 1.90.0 but does not work in 1.91.1. Steps to Reproduce [Windows Sandbox]: a Windows Sandbox Edge and download VS Code (stable) from the VS Code website the C# Dev Kit extension. Note: Upon install the walkthrough is supposed to launch automatically. This is not happening, but I can manually open the walkthrough using these steps. command palette. command 'Welcome: Open Walkthrough' 'Get Started with C# Dev Kit' ! steps 3-7 with the Python extension. Same behavior. Steps to Reproduce [VS Code stable and VS Code insider]: VS Code C# Dev Kit (if you have it installed) VS Code C# Dev Kit extension. Note: Upon install the walkthrough is supposed to launch automatically. This is not happening, but I can manually open the walkthrough using these steps. command palette. command 'Welcome: Open Walkthrough' 'Get Started with C# Dev Kit' steps 2-7 with the Python extension. Same behavior.
closedWith
using the steps above, I am not seeing the walkthrough open when I reinstall the extension
Was just talking with about this- if you've had it installed in the past, it won't work, but for me it works in a window with a clean user-data-dir
To prevent issues like this: and like this and many more
this is a good idea, I've been getting tagged in a lot of these recently. it's difficult to say what exactly the limit/requirements should be though. atm we require title and description (the rest of the info is fluff that is auto included). Maybe force description to be longer than 10 characters?
We can start with 10characters enforced on both title & body and see how issues keep coming. We could also maybe crowd-source ideas from the team
While testing . VSCode Version: Code - Insiders 1.15.0-insider (, 2017-08-01T05:07:59.267Z) OS Version: Darwin x64 16.7.0 Steps to Reproduce: 3 terminals from the command palette <kbdArrowDown</kbdto the last terminal in the switcher <kbdTab</kbdto rename the terminal -keyboard focus disappears from the input box (and seems to be nowhere). I need a second <kbdTab</kbdto move the keyboard focus to the rename action in the selected row. A single <kbdTab</kbdshould suffice.
This is also an issue with task configuration
Screen reader and low vision (or other accessibility) users often use our menu items to discover things. We should include a menu item to open the getting started walkthrough under .
and WDYT?
Seems reasonable to me. The title suggests that it could also be a walkthrough, or part of an existing walkthrough. The tradeoff there would be discoverability.
I see an error in the console when opening accessible view from that welcome experience:
Cc
Related:
<!-- 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: a ntoebook click on a cell, and notice the order of the cell actions same entries for regular editors is All places the order is We might want to consider changing this.
is this a papercut or ux issue I'm concerned that changing this now could result in issues due to muscle memory (i.e. users being used to this order). Thus changing this might not be a good idea, then again, i don't think it is. Thoughts?
discussed with team, Lets change this
Testing Show extension display name instead of extension id. You can also make them links to open the extension editor. <img width="522" alt="image" src="https://user-"
what's the right way to do this? I had a look and could only see async methods to do this which seemed odd to me (and would require some refactoring to get the tooltip to work with async).
1 I see this as well
There are multiple ways depending upon the source of this extension id. Since it is a running extension, I would prefer to use this api since you do not want to have async
thanks will use that. You don't have an id -name map to avoid iterating over it multiple times though?
There exists one, but it is async
<!-- 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: type and enter that issue reporter is opened with correct extension selected. !
/gifPlease
Thanks for reporting this issue! Unfortunately, it's hard for us to understand what issue you're seeing. Please help us out by providing a screen recording showing exactly what isn't working as expected. While we can work with most standard formats, files are preferred as they are displayed inline on GitHub. You may find helpful as a browser-based gif recording tool. If the issue depends on keyboard input, you can help us by enabling screencast mode for the recording ( in the command palette). Lastly, please attach this file via the GitHub web interface as emailed responses will strip files out from the issue. Happy coding!
The terminal's usage of may have regressed?
The issue I'm seeing is no longer seems to flip the terminal link modifiers and column select modifier. Additionally the cursor isn't showing anymore when using column selection.
Actually I don't think it ever flipped the column select modifier
When is set, alt+click still opens fine. After the crosshair will be working as intended, the link pointer cursor will override it correctly.
! I can still repro if . Is there something else I should set? It works fine if I set .
Since verification steps are needed and is OOF, this issue will be moved to the February 2024 milestone.
in case you know the verifications steps.
I verified that regardless of the value of , I can open links in the terminal with ctrlCmd and holding alt allows me to do column selection, which I believe is by design.
It turns out that the bug has nothing to do with the cross cursor. The real cause was extension host keep crashing after a few minutes after opening a big TypeScript monorepo.
<!-- 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: 1.72.2 OS Version: macOS Monterey 12.5 Steps to Reproduce: custom HISTFILE (example custom HISTFILE per project) integrated terminal (zsh) in VS code will be /Users//.zsh_history instead of custom history file What i use: vscode I found that the changes made to break the ability to use a custom HISTFILE because the HISTFILE is always overwritten by these changes:
Trying to set HISTFILE directly in settings, fails the same way HISTFILE is always set to
Hi I have opened a PR with a possible solution to this issue. Let me know, if it solves the problem.
thanks a lot Sorry for the stupid question, but do you have any macos silicon build that I could try ? I never contributed to vscode and finding how to compile it from source may take some time
Unfortunately, I don't have a Mac, however, I use Linux with Zsh so I could reproduce the bug and I could test the fix on it.
I think this might be related to with McFly.
Type: <bBug</bTo reproduce: VS Code a folder and choose a git repo with changes a file with changes and notice the gutter is shown a folder to the workspace and choose a git repo the gutter is still visible close the file and reopen it Expected behavior: the gutter is shown Actual behavior: the gutter is not shown this may be related to . actually pretty much the same issue. However a reload (I assume that is ) doesn't help in this case. VS Code version: Code - Insiders 1.77.0-insider (, 2023-03-10T05:24:23.805Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: Yes <details<summarySystem Info</summary </detailsExtensions: none<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for the @ mention and for the repro steps!
Also having the same issue. Installing a previous version () helped to solve it (temporarily, until it's fixed).
Folks who are seeing this issue: Could you please install the latest insiders build and confirm that you no longer see the issues there?
Yes. The issue resolved in the latest insider version.
Related Stack Overflow questions: I'd prefer using this one as a duplicate target on Stack Overflow since it's asked much cleaner.
Thanks for confirming that the issue is fixed in insiders!
Wow, so it was a bug, not an actual symlink-issue as I thought. So happy now, thanks! Context: I'll try the fix/update.
This issue seems to be fixed in version 1.76.2 for git repositories, however it is not yet fixed for Mercurial ( extension).
I am still seeing this bug in
can you share some exact repro steps that we can use to reproduce the issue?
I can't reproduce the issue on a new clean git repo, hmm
Im having the same issues, reinstalling helped fix the current file having the issue but any file created after wont show the indicators. Disabling extensions wont work either and Im not sure on how to reproduce the steps Version: 1.76.2 (user setup) OS: Windows_NT x64 10.0.
Testing If there's no error case, I now need to return something like:
Hi we have branched off from today, so I am pinging about the milestone here. Would you like to make this issue a candidate or move it out to the milestone?
Moving to March for now. Feel free to move this issue back to February if it turns out to be a candidate.
It's already a , which allows 'undefined' but not void. Is it weird to say ?
+1 on this, I have to explicitly today
<!-- 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.39.0 OS Version: Linux RHEL 7 Steps to Reproduce: code with --no-proxy-server flag "Option 'proxy-server' is unknown. Ignoring." error appears. I think the proxy is still disabled, the error message is simply wrong? If I run without the flag, I get prompted to log into the proxy, if I run with the flag, the proxy appears disabled (no log in prompting) but the error appears on the command line.
I suggest to include that fix in the recovery builds to avoid any confusion due to the message printed by the cli. The cli says for all chromium options, but in fact, they are used. My understanding is that most of the chromium options are not for the end-user except and the proxy settings, so I these to the list of the valid (supported) args. Please speak up if I missed one of the options. PR is
This is not fixed in the latest stable release candidate. The reason is that the PR was actually not merged and this issue was closed erroneously
The discussion in yesterday's standup was to take this, so we've now merged the PR...