jiebi/CodeConvo huggingface dataset:
Thanks
The above solution solves the performance problems I have been having for a long time when starting VS Code. It seems that the line reading problem has been solved as well. However, when I leave the focus on the file browser for a minute or so, the problem persists and nothing else can be done. If I press ctrl + shift + e and switch contexts, the focus returns, but now I have lower performance with NVDA, which causes me to have to restart the screen reader anyway. Thanks
After some time, I have been able to verify that it is still not resolved, but it does not happen in all cases. The performance issues in VS Code at startup seems to be the only thing that was fixed, apparently. I hope you can keep and merge the changes from the above proposed solution because now I don't have to restart the screen reader after starting VS Code, which is much nicer. However, the other two problems still persist. Standing still for about a minute in the file explorer results in not being able to focus on anything. The line problem I can now only reproduce with an extension, but it uses the same Monaco editor as VS Code. Install eamodio.gitlens extension. Now, focus the file explorer and look for a file with the arrows. Press shift f10 and scroll down to open file history. Then, choose any commit and press enter, then f6 to go to the editor that opened. There the lines do not read well. For example, given this file from a Ruby on Rails application: Pressing up arrow or down arrow always reads this, except in the last line that reads blank: Thanks
I just installed the build posted above: VSCodeUserSetup-x64-1.75.0- and now, everything works as expected. The screen reader no longer locks up on me every minute or so! This is great... Hopefully, this will give the team enough information to track down this bug! I will leave updateMode set to "none" until I hear that this bug has been squashed. Thanx for the fix! -- Rich
I investigated further and the problem was indeed solved. While changing "" to none VS Code downloaded the update. I uninstalled and reinstalled and everything is fine. Thank you very much!
I hope you can release this solution quickly, as I can't use this specific code-insiders version with WSL. Try to install but I get 404 error.
I agree that your test build seems to have solved the issue and navigation feels crisper and more responsive. Please update insiders and also a patch release to 1.74 since this does not work with WSL or devContainers.
thanks for confirming the fix, it will be available in Insiders today. Can you also respond to comment in about any missing steps which will help us on our end to verify the fix. Thanks! We just had a patch release yesterday , you should be able to use the normal insiders with the fix on both WSL and devcontainers until we make a release. Also, we will need the steps to verify if we want to make a patch release to stable. I will update here again once the fix is available with Insiders.
Insiders has been released with the fix, you can get insiders from
the steps are in this , for the line reading and freezing problem Thanks for the solution!
FOr me, the problem would occur when I was simply navigating the interface. It was most apparent, and seemed to be triggered more quickly, when navigating a menu like view (alt+v, then up/down arrows). Question: I'm seeing behavior that I've never seen in other menus -- if I open view with alt+v, navigate via downArrow, escape out of the menu, then come back in with alt+v, it almost never focuses on the first menu item, but somewhere in the middle. Is this intentional? Thanx for all the work on this! -- Rich
I cannot say I noticed a repeatable pattern, but it was much more likely to occur when navigating around the UI in areas like the explorer, settings, extensions, menus, etc. than just staying within a single file. So it doesn't surprise me that steps did not reproduce the issue.
Closing since we have pushed a fix for this. Adding a verified label based on users confirming the issue is indeed fixed (since we can not reproduce ourselves). If some users can it would also be helpful to verify with the stable build that is about to come out in the next 24 hours.
Here's the links to the build depending on your platform darwin: darwin-arm64: darwin-universal: linux-arm64: linux-armhf: linux-deb-arm64: linux-deb-armhf: linux-deb-x64: linux-rpm-arm64: linux-rpm-armhf: linux-rpm-x64: linux-snap-x64: linux-x64: win32: win32-archive: win32-arm64: win32-arm64-archive: win32-arm64-user: win32-user: win32-x64: win32-x64-archive: win32-x64-user:
Yes, it's also fixed in 1.74.2.
<!-- 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.29-insider OS Version: Windows 10 Version 1809 (OS Build .1000) Steps to Reproduce: Find in files and search for something that will return results over different result lines Badge and Action button (Dismiss) are on the left (aligned to the end of result text) I'm expecting that Dismiss action will have fixed horizontal position (on the right side) that will allow me to easily dismiss several results entries. With current position at the end of result text I have to constantly move mouse to hit Dismiss button. In stable version both count badge (for file) and Dismiss action were aligned at the right side of the viewlet which was convenient. At this moment it is hard to filter out result entries because texts have different length and button shifts for each line. I've found which says that button should always stay on the right side, however this isn't case in v1.28.2 independently from viewlet width (both badge and actions are on the right side). <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <details<summaryScreenshot</summary<div! </div</details
I guess this only applies to the search panel?
Yes, I observe issue in Search panel. UPD. Checked - same behavior when Search: Location is set to sidebar.
You should see the actions on the right when search is narrow, and on the left when it's somewhat wide. The reason is that when the actions are on the right and the text is aligned to the left, it can be hard to associate the two, so it seems more user-friendly to put the actions closer to the actual result. Maybe the threshold could be tweaked, but it doesn't feel good to click an action on the opposite side of the monitor from the actual text. Does this match what you see?
Yes, that match what I see, but makes it harder to use Dismiss action with mouse. For badge with results count - it is good position, since it is visible without hover. On the other hands actions are only visible on hover, when background can clearly indicate what line will be dismissed.
Previously (September and numerous builds before) I was able to put mouse over X and just click (even without looking) several times to remove unnecessary lines. Now it takes more time/attention to do it with mouse, and if next line after dismissed has longer text - it is easy to open file instead of dismissing it. Open editors view (Close editor button), Source control (action buttons for files), Extensions (Manage button) - have static position of actions that are not changed with sidebar width. My cases are 23" monitor with 1920x1080 and Surface Pro 3. Never had problems when action were on the right side. Users with 4k 30+" will have to snipe for X too.
Yes it was broken for a few months, but this was the behavior from before it was broken I see your point but I will leave this open to think about it
thanks!
Putting the dismiss button to the right would also make it less likley that someone presses it by accident which I just did. The middle of a search result might be just above/below the end of another so that clicking just a bit above/below where you intended could lead you to remove the other search result.
Issue 1) The dismiss buttons are too close to the actual text of the search result making it very easy to accidentally dismiss something. Issue 2) The dismiss buttons are invisible until hover/focus. So if you had your focus on another panel or another window and then click on a search result to focus it, it's too easy to click on an invisible button and accidentally dismiss a search result because of issue 1.
Trying to decide whether we should just always right align... but it seems weird to me to have the X really far away from the row content in some cases. Anyway, if someone wants to add a setting to configure this, I would take that PR.
Open notebook with a header, code cell, and symbols in the code cell: # 1: symbols appear as a child of the header md cell, and the code cell is not present in the outline. # 2: changing the filter settings to remove code cells or symbols does not recompute the outline. Fixes: For # 1: an outline provider was being created with the incorrect target (sticky scroll was created with a QuickPick target), and this was being retrieved for the outline pane incorrectly. For # 2: one of the locations an outline change event is fired was shifted and subsequently removed, meaning that the outline did not recompute to reflect the filtered-out cells.
Hi ! I am running into an issue issue when using vscode 1.66 : when running pymc models there is a progress bar output which was working fine before the update and now the progress bar simply prints down :( See pic below ! This is how it prints in Jupyter notebooks (anaconda) and it was looking so in vscode 1.65.2 ! Here is the info about my session
Update It actually works when I am not looking ie, I am not in that specific cell of the notebook ¯()/¯ !
Here is a reproducible example: Code: Output: !
I'm having a similar issue using enlighten progressbar. This likely started after a recent vscode update. A new progressbar is printed everytime it updates/redraws. I'm guessing this is the same issue. (This works/prints fine when run using jupyter-notebook on a web browser) !
Thank you for working so fast on this one! Looking forward for the next update/release !
I couldn't verify this fix, using : !
thanks, it's not being picked to the release branch yet.
Works for me too. !
I wanted to customize my keybindings depending on the OutputPanel state, but it looks there's no clause to set in the stanza for it.
There is a context , please try that
Ok that works when if focused (but needs to be documented), what about when it's visible?
We accept PRs that update our docs. Checkout the vscode-docs repo. No this is not currently supported, we accept PRs that add this. Code pointers Similar to the viewlet service here The panelPart would add a context key
works but how does a user learn the panel ID?
good point. However we already had that issue with the viewlets, since we already have a "activeViewlet" conext key. We should document this properly
Including all who have commented : New SelectBox implementation: Standard native select allows navigation to an item using the first character. This can be done both on a unexpanded or expanded select. Should this behavior be implemented in the new custom SelectBox ?
yeah good catch I think it should. If the control has focus at least. Please do not assign the "candidate" label to issues. It is reserved for issues we plan to fix in a stable recovery release.
though assigning milestones is usualy a good idea, if you plan to fix this until the end of january just assign to December / January milestone.
Noted on the labeling issues (verified, candidate, milestones), sorry don't know all the workflows :-( Sorry to pepper you with a few more questions: I saw you wrote a draft test plan, would you like me to add some more specificity on keyboard support so people know exactly what to look for? If I have small tweaks/cleanup should I create an issue(s) or is using notes in a pull request sufficient? Essentially when is it appropriate Not to do an issue for work in progress? I will fix all issues posted for the December/January milestone assuming they are known in time.
yeah feel free to make tweaks to the test plan item: I also published some release notes on it here: The advantage of having an issue is that it will get verified in the endgame if it is a bug. If the thing you are changing cannot be verified or is not a bug, doing just a PR is fine.
You chose selectBoxCustom for the filename, do you prefer that I re- factor the delegate class and symbols to use custom instead of list?
no I think its fine
Fixed with:
<!-- 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. --With the above settings in effect and a terminal open in the bottom panel: If the terminal has focus, the cursor blinks If the terminal doesn't have focus, then the cursor remains visible without blinking Unlike the block-shaped cursor, which becomes hollow when the terminal loses focus, the line-shaped cursor doesn't change appearance when the terminal loses focus; it merely stops blinking. This makes it hard to tell at a glance whether the terminal has focus. So that it's easier to tell whether the terminal has focus, I would like an option to customize how the line-shaped cursor appears in the terminal when it doesn't have focus. Possible options (not exhaustive): Hide the cursor altogether Keep it visible, but make it (say) 50% opacity Show the same hollow block that's used with the block-shaped cursor
I actually thought it showed the hollow block in this case, I think that makes the most sense
try try
We're going back on the decision made in and making unfocused show the rectangle regardless of cursor style. Discussion:
Type: <bBug</bWhen editing a Markdown file, VS Code will apply LaTeX syntax highlighting to math in double-dollar signs (math blocks), e.g., will color and and the numbers. GitHub Markdown also supports a code block syntax (the triple-tick syntax; see ), so the above could be written in GitHub-flavored Markdown as <img width="200" alt="image" src="https://user-"It'd be nice if it could apply the same highlighting as double-dollar signs. VS Code version: Code 1.75.1 (Universal) (, 2023-02-08T21:34:59.000Z) OS version: Darwin arm64 22.2.0 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<details<summaryExtensions (19)</summaryExtensionVersion ------ prettier-vscode9.10.4 linter-gfortran3.2.0 unicode-math-vscode0.3.5 isort2022.8.0 python2023.2.0 vscode-pylance2023.2.30 jupyter2023.1. jupyter-keymap1.0.0 jupyter-renderers1.0.14 vscode-jupyter-cell-tags0.1.6 vscode-jupyter-slideshow0.1.5 cmake-tools1.13.45 cpptools1.14.3 cpptools-extension-pack1.3.0 vsliveshare1.0.5831 rewrap1.16.3 cmake0.0.17 clang-format1.9.0 markdown-all-in-one3.5.0 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
<!-- -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!
Yay, 23 upvotes!!
<!-- -c9e0-7adb-d31b- --:slightlysmilingface: This feature request received a sufficient number of community upvotes and we moved it to our backlog.
<!-- 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. --Version: 1.78.0 (user setup) Commit: Date: 2023-05-03T20:09:00.748Z Electron: 22.4.8 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: Windows_NT x64 10.0. Sandboxed: No I've reported a bug related jupyter notebook before . After new release of vs code this below bug happens. Steps to Reproduce: https://user- a Jupyter notebook file that contains some images. to view images and see what happens.
I'm not seeing this repro - can you try disabling all extensions and opening that same notebook to see if it still repros? Also check which renderer is being used for the image by selecting 'change presentation' in the output menu !
I've provided info about you asked in the video. extensions are disabled was using 1. as seen in the image and video. tried other renderer as well to show difference. another issue is; VS Code is scrolling down own its own when notebook is opened first time and loading of output started. It can be observed below in end of video as well. I cannot hold the page and have to scroll back by myself. !
How many images are you displaying there? (I still don't see it with 500, though perf takes a big hit) Does it repro with a smaller number of images? Like just displaying the same image 10 times.
Do you know if all the images are being displayed? I see some suspicious collapsed borders in between a few. Can you try and reloading to check if there's a setting causing this? ( to default to switch back)
Alright, I have tried the way you told me and created new profile and didnt install anything at all. But it seems that doesnt change. I dont have a notebook that have few images. The notebook have 618 images as it could be seen in the video before images output says that 1/618, 2/618 .... 618/618. Those are the images is saved in storage after that they are being displayed. As far as i noticed those movements only occurs when notebook is being loaded. Because if load finishes that movement seem to stop as well. Another thing is there is something wrong about loading process as it could be seen in the video. I especially didnt use mouse's wheel not to confuse you, i only used scroll bar on the right. VS Code stops loading/showing images after some point untill i scroll down bottom and if i come back it suddenly appears. And i wanted to show how google colab loads in the browser.
<!-- 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!
are there verification steps for this?
verification steps a notebook and put a small image in your local workspace a cell with the code: the cell and wait for completion, (finished for me in a few seconds) , close, and re-open the notebook the images might take a bit to all render, but they shouldn't bump up and down once they are visible
Same bug (bumping up and down) still persists for me. Another thing is loading of images are stuck some point and it's fixed if i scroll down to bottom and come back. I showed and explained the bug which was in vscode.mp4 video and duration between 00:42-1:20.
Version: 1.79.2 (user setup) Commit: Date: 2023-06-14T08:57:04.379Z Electron: 22.5.7 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: WindowsNT x64 10.0.
This fix is only on VS Code Insiders right now. It looks like you're still using the stable version.
Type: <bBug</bPressing Alt+] and Alt+[ in Accessible View includes redundant aria alert before new content. On Windows, NVDA and JAWS users hear the following info first whenever they press Alt+] and Alt+[ in Accessible View: I have tested with Accessible View against inline suggestion. Please exclude this message from the aria alert. VS Code version: Code - Insiders 1.82.0-insider (, 2023-08-17T05:33:29.141Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (89)</summaryExtensionVersion ------ android-dev-ext1.3.2 Bookmarks13.4.1 openscad1.2.1 spellright3.0.116 zoterolatex0.4.1 mermaid-markdown-syntax-highlighting1.5.2 doxdocgen1.4.0 vscode-markdownlint0.51.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.20.0 gitlens14.2.1 EditorConfig0.16.4 prettier-vscode10.1.0 vscode-google-translate1.4.13 codespaces1.14.15 copilot1.104.343 copilot-chat0.7. remotehub0.60.0 vscode-github-actions0.26.1 vscode-pull-request-github0.70.0 easy-snippet0.6.3 path-autocomplete1.24.1 latex-workshop9.13.4 lilypond-syntax0.1.1 scheme0.2.0 better-cpp-syntax1.17.2 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.0 black-formatter2023.4.1 flake82023.6.0 isort2023.11. python2023.14.0 vscode-pylance2023.8.30 jupyter2023.7.
jupyter-keymap1.1.2 jupyter-renderers1.0.17 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.305.0 remote-ssh0.105.1 remote-ssh-edit0.86.0 remote-wsl0.81.0 vscode-remote-extensionpack0.24.0 azure-repos0.36.0 cmake-tools1.15.31 cpptools1.17.3 cpptools-extension-pack1.3.0 js-debug-nightly2023.8.1117 powershell2023.6.0 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.129 vscode-selfhost-test-provider0.3.16 vscode-serial-monitor0.10.0 vsliveshare1.0.5877 resourcemonitor1.0.7 autodocstring0.6.1 pandocciter0.10.3 shiny-python0.1.2 shinyuieditor0.4.3 quarto1.94.0 r-debugger0.5.4 java1.21.0 vscode-xml0.26.1 r2.8.1 multi-command1.6.0 vscode-deepl1.0.6 abc-music0.4.0 lua3.6.26 latex-utilities0.4.10 cmake0.0.17 errorlens3.13.0 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-arduino0.6.0 vscode-java-debug0.53.0 vscode-java-dependency0.23.1 vscode-java-pack0.25.13 vscode-java-test0.39.1 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 --
can you pls try in insider's? I made some changes yesterday that should've fixed this.
This issue still exists in the latest insider that I have updated today.
That info, 'Inline Completions Accessible View' was formerly provided via the aria label.