jiebi/CodeConvo huggingface dataset:
Type: <bBug</bExpected: ! Actual: ! Steps to Reproduce: a file. one configuration for any language. in ${} block and intellisense doesn't provide proper hints. More Info: bug is likely related to and . bug can be reproduced in 1.79.0-insider. VS Code version: Code 1.78.2 (, 2023-05-10T14:39:26.248Z) OS version: Windows_NT x64 10.0. Modes: Sandboxed: No <!-- generated by issue reporter --
Going way back to , this change seems right since the configuration-editing extension has contributions for these languages but the extension doesn't actually activate unless I add explicit activation events. I can't figure out why the auto activation event isn't kicking in?
Oh, sorry--we revised the event to only do auto activation if the extension also contributed a language definition for that language, since otherwise this led to extensions like Python being activated too eagerly. For debug we should restore the explicit activation events too.
I see, thanks
I notice that when I edit our 1.9 release notes, the markdown preview seems to jump up and down all the time there is a change. Compared to 1.8 stable, this seemed to not happen.
Better, I still see flickering that it jumps up and down a little bit and the decoration to the left to show me the current edited location is also flickering. let me know if I should open a separate issue on that or if you think that is fixable.
The flicker should now be better than VSCode 1.8, but we can still do better. I've noticed the same sort of slight flicker on images in particular and on the current paragraph indicator as you noted. Please open another, lower priority issue so that we can track further improvements Thanks
Build:
Hit this again with
Again:
is trying to get more details when this happens:
Also saw this
This is because of atomic writing and in windows renaming is failing sometimes and I think this is because some other processes (defender ) might be holding the file that has to be renamed. I have seen similar issues in extensions when I implemented atomic installation of extensions long time back, ie. extracting the zip to a temp file in the same folder and renaming it. I have to retry renaming multiple times to avoid this. I am not sure if this is the right solution for FS atomic write. So, I would wait for until then I will revert my atomic write changes.
Check this issue - This is common in windows and it seems the workaround is to retry.
should the skipped tests be restored, I think they are still skipped
Seems like they can probably be restored.
Type: <bBug</bcc: Since Friday the 3rd, I have not been able to access the terminal accessibility buffer in my linux environment. I activate a terminal and am informed by orca about accessibility in the terminal. But pressing shift+tab does not move the focus to the accessibility buffer. Am I doing something wrong or has something changed from day 3? VS Code version: Code - Insiders 1.77.0-insider (, 2023-03-06T05:21:55.128Z) OS version: Linux x64 6.1.14-200.fc37.x8664 Modes: Sandboxed: Yes <details<summarySystem Info</summary </details<details<summaryExtensions (39)</summaryExtensionVersion ------ doxdocgen1.4.0 vscode-markdownlint0.49.0 vscode-chatgpt3.9.4 rest-client0.25.1 better-cpp-syntax1.17.2 azure-pipelines1.208.0 vscode-docker1.24.0 csharp1.25.4 vscode-dotnet-runtime1.6.0 vscode-kubernetes-tools1.3.11 remote-containers0.283.0 remote-ssh0.99. remote-ssh-edit0.84.0 azure-account0.11.3 cmake-tools1.13.45 cpptools1.14.4 cpptools-extension-pack1.3.0 makefile-tools0.6.0 powershell-preview2023.2.1 remote-explorer0.3. vsliveshare1.0.5832 oracledevtools21.5.0 fabric8-analytics0.3.6 java1.16. vscode-xml0.25. vscode-yaml1.11.0 sonarlint-vscode3.15.1 cmake0.0.17 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 vscode-boot-dev-pack0.2.1 vscode-spring-boot1.44.0 vscode-java-debug0.49. vscode-java-dependency0.21. vscode-java-pack0.25. vscode-java-test0.38. vscode-maven0.40.
vscode-spring-boot-dashboard0.11.1 vscode-spring-initializr0.11.2 (1 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
You can use this command for now, but I can repro the issue
The other change that has been made here is tab moves focus mode has to be on for that keybinding to work. This prevents issues where the terminal should be handling shift + tab such as for or autocomplete. The clause for this command can be configured in the keybindings editor though if you do not like this behavior.
After using the command Terminal: Focus Accessible Buffer, the behavior was a little strange. focus is on the accessible buffer, the tab key does not move focus to the terminal, but to the status bar. When I'm in the accessible buffer I need to press tab and then shift+tab to access the terminal. seems that the accessible buffer is not always updated when I execute a command in the terminal.
Yes thanks, covered in these issues:
Testing Works on macOS but not on Windows 11 !
Works for me on Windows 11. at the lack of command start decoration on the following line in the screenshot where this doesn't work. !
Logs from
is happening after the next in the above, which is pretty weird. We try to detect quick fixes , so it's not surprising this is failing. any thoughts?
I likely caused this when making command markers more reliable on Windows
Seems this is broken for the non-polling case, which is why I am not seeing it (with starship).
Testing ! !
This is because of the same problem that caused
appears to be closed now, does that mean this has been fixed?
No, this issue is about fish acting atypical in that it applies the environment before is applied. This is because of how the automatic injection works in fish via an environment variable. Still not sure how we can handle this.
Discussed offline, maybe we could use the first pre exec hook in fish to run shell integration, instead of .
Nice !
<!-- 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. --For Anonymous functions code lens is displayed although it has only one reference. This is a lot of noise for nothing. In my opinion these lenses can be removed completely.
This issue lacks name of the language/extensions that you are using/showing
You are right. My bad. I fixed it. Sorry.
Requires: -
I in those required settings and am seeing the screenshot below. Seems to now only say 0 references instead of one but the code lens still exists !
I think the screenshot shows the expected (fixed) behavior. Previously the references codelens was on the line with . There are zero references because there are no uses of that class or method
yep - this is exactly what I wanted.
<!-- 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. --Hello! Could you please allow for the output.ReverseAttributes to be defined as a user preference setting? This was implemented to and was implemented in the current emmet repo Why is this important? With Bootstrap, all of the generated code samples implement class attributes at the beginning of a tag. For example, a generated (As a note, this is how I've generally seen and used bootstrap classes implemented inside a tag), might have a section that looks like this: to add a new anchor with the same syntax, I would want to use the follow emmet syntax: However, the preview generated, and the implementation do not give me the style that I prefer: ! Now, I could implement a snippet for this specific anchor override, but now if I want to use this style across the codebase with all of my tags that utilize bootstrap, I now have to create a file that grows exponentially to cover every use-case. Since solves this behavior, I figured I could do add this override in my code workspace settings, such as But this did not work. also does not have a supported object for preferences based on . I think this might also open a bigger question of "How can VSCode support any arbitrary snippet preference? (There are many from where this specific attribute was implemented) There doesn't seem to be a method to implement this behavior via the regular so if I want this behavior today, it seems I would need to fork emmet and vscode, and implement my own custom implementation to enable this feature toggle.
thanks for the write-up. I wasn't aware of when output.reverseAttributes would come in handy. What I do know though, is that VS Code is currently using an older version of Emmet. Once it moves on to the newer version (the one you see at emmetio/emmet), it should be much simpler to get that preference implemented. I'll keep this issue open in the meantime.
Sounds great! Thanks for the quick response, looking forward to the newer version of Emmet being implemented!
Created a PR fixing this
<!-- 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.63.2 .Steps to Reproduce: an error while coding, and open the "View Problem" box. that the up-arrow has the label "Goto next problem". Ideally it should be "Goto previous problem". !
You accidentally closed this let's reopen and assign to me. fyi
<!-- 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.84.2 OS Version: win10 Steps to Reproduce: Theme: Dark Modern two cpp files in the workspace, move the tabs upwards and downwards respectively. +N, Open a new Tab, and copy some content into it. Move the tabs upwards and downwards respectively. When I move tabs downwards, the edge color disappears. Another sample This issue can be reproduced in vscode-insider
I'm not able to reproduce this. Can you check if you see an error in the dev console? Run the command and check the console for errors.
You can try with a larger cpp file, simply copy code to many lines. Drag the tab down to change the tab's position
It seems the tab scrolls down, so the color bar is blocked
I was able to reproduce it now. The reason I was not seeing it was because it only appears at specific zoom levels. Looking into it...
Thanks for the help we were able to fix it
This problem seems to still exist in the latest vscode-insider. ("window.zoomLevel" : 0 ) 86.0-insider x64 With untitled tabs, the tab can be scrolled down and up, Besides, It seems that the .json file is an exception
<!-- 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.66.0 OS Version: MacOS 11.5.2 Steps to Reproduce: the relevant lines to to enable the prompt it works in regular OS terminal (outside VSCode or inside VSCode without experimental shell integration) <img width="302" alt="image" src="https://user-"the experimental shell integration in VSCode the integrated terminal, visit the same location and see the error <img width="298" alt="image" src="https://user-"
I wonder if instead of replacing the entire , the VSCode change could update it with concatenation so that existing commands remain as they are?
the approach we're taking is to wrap the function, also we need some code before and some code after the original prompt and bash can have it in a bunch of different formats so it's not as easy as it sounds.
/closedWith
Re , I was editing the endgame notebook in VS Code repo but it keeps moving the cursor to the next line, which breaks typing. It's very likely an issue with these two settings combined "files.autoSave": "afterDelay" We seems to have the same issue for files in text editor but untitled file doesn't suffer from this as it can't be auto saved. I wonder if we should have some special treatment for notebook cells, as it's very usual to create new cells, which are always empty at the beginning, typing in the first line is making it almost impossible. Maybe we could keep the cursor position for this scenario.
Microsoft/vscode Repro: PR ext description page something, shift+tab until you hit the start of the screen There are 4 focusable items, close, next match, previous match and the find input.
Would you like me to start on this?
Yes please. It is too late to get a fix in for the January VS Code release but you can submit a PR any time and we'll try to get this fixed for February
LOL ... my Dragon dictation did the equivalent of a butt dial , deleted assignments and pasted an eMoji sorry about that :-P
FYI: started on this and I can reproduce and see it. simpleFind transitions in and out with animation, hidden only because of z-index and/or overflow. The widget always has display type:flex , therefore the four tabs stops for the buttons and input are always in the tabIndex order fix should be simple, however, there is an interaction between the animation and the display mode such that simultaneously going from display:none =flex messes up the animation. I'm working on separating the display mode from the transition to see if that will work. I have to do more experiments , May have a question or two later...
See PR: Verification: Use a screen reader with screen output on so you can see and track each tab stop Open the new pull request extension page Click on the upper pane to begin focus there Tab through the various toolbar buttons , after dependencies the next tab SHOULD land on With the webview not the simpleFind widget. Verify showing and hiding simpleFind has smooth animation as before Note: When focuses on bottom for web view pane , screen readers output a bunch of base64 encoded text (see truncated output lines below). But I think this is an accessibility bug, if you guys agree I'll post an issue. NVDA Output: with visibility fix (correct output, no tab stops within the hidden simpleFind) NVDA Output: original scenario without fix (can see tabs stops in widget)
Issue Type: <bBug</bI have been using for a long time. Currently I end up with a LOT of inadvertant selections when working in two side-by-side editor groups and switching back and forth between them using the mouse. The reason is that the editor scrolls 5 lines every time I click into it. VS Code version: Code - Insiders 1.58.0-insider (, 2021-06-11T05:22:19.992Z) OS version: Darwin arm64 20.5.0 Restricted Mode: No Remote OS version: Linux x64 5.4.0-1046-azure <!-- generated by issue reporter --
I cannot reproduce. Does this reproduce for you when disabling all extensions? (The editor exposes a API to extensions). I have recently also got which seems incredibly similar, but I am having a hard time reproducing any of the jumping that is described. Here I am trying two side-by-side editor groups: https://user-
This reproduces only when the language mode of the files are set to markdown. I think this has to do with how the markdown extension is using the vscode API. But I think it should not use that API at all if no markdown preview is rendered. But it would also be interesting to test what the experience is when the preview is rendered. Given this doesn't reproduce with txt files, I'm optimistically giving this to you. Steps to reproduce: define open two md files side-by-side (preferably without word wrapping to see the top line number change) click on the editor tab of each one on every click, the editor scrolls up by 5 lines https://user-
Could you please take a look at this since you were looking into markdown syncing last iteration?
It seems like it's a bug coming from the scroll syncing between the static and text editor changes that I made a while ago. I'll try to make a PR to fix this soon.
<!-- 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.88.1 (Latest) + GitHub Codespaces OS Version: All? (Tested on Linux + MacOS) Steps to Reproduce: a folder or workspace (create if necessary): all the content from the above file and save it the command palette 'Tasks: Run Task' '+ Configure a Task' 'Open file' any provided task template notification error: "Unable to write to Folder Settings because no resource is provided." Expected behaviour: Empty is populated with the contents of the selected task template <img width="898" alt="Screenshot 2024-04-18 at 16 50 01" src=""
! should be highlighted: ! Version: 1.77.0-insider (user setup) Commit: Date: 2023-03-21T05:22:13.879Z Electron: 19.1.11 Chromium: 102.0.5005.196 16.14.2 V8: 10.2.154.26-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes
cc for TS
I cannot reproduce, semantic occurrences seem to work fine for me. can you reproduce running from source? !
I can repro out of sources as well
Looks like a windows specific issue (slash vs backslash): ! ! (in TypeScriptDocumentHighlightProvider.provideDocumentHighlights)
Reverting fixes it.
Hm I don't think this was caused by . Instead I suspect the root cause was
<!-- 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.71.0 () OS Version: macOS 12.5.1 (21G83) Steps to Reproduce: any file on . the filename tab on the "Editor", hold + Click on it (the same as a right-click or two-finger click on macOS). See the image below ! Expected: it opens the context menu with options about the file. Actual: it blinks the context menu for a fraction of a second. A screencast of the problem: ! The problem doesn't happen on VS Code desktop.
I can reproduce, and maybe is an issue that would reproduce on desktop too but we use native menus there and not custom menus.
is this ctrl+click behavior mac specific?
I am not entirely sure, but so far, we have only seen reports about this issue on macOS.
Yes, Macs by default consider CTRL+Click a right click. This works across the entire OS.
This is great, thanks for the fix!
<!-- 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. --This proposal affects Settings editor (Settings UI) users and extension authors. The search in the Settings editor currently shows results sorted by the table of contents so that commonly used settings can show up at the top, and so search results can be grouped by the entries in the table of contents. The change to sort the settings by table of contents was made as part of and However, the Settings editor performs two searches per query: the first search finds settings based on keyword matching, and the second search attempts to find relevant settings using similarity search algorithms. As a result, the second search is prone to finding less relevant settings, especially when the user had a specific keyword in mind. Because the Settings editor currently orders settings by the table of contents, the less relevant results from the second search sometimes end up showing above the keyword match results because they appear first in the table of contents. As an example, if I search "title bar style" in the Settings editor, actually shows up fifth due to table of contents sorting: ! This issue proposes reverting the settings search so that the keyword matches always appear at the top of the search results again. As part of this proposal, and would regress and become out of scope. In other words, ordering the search results so that keyword matches always appear first would break grouping the search results by the table of contents entries, but would make it so that users hopefully don't have to scroll down as much to find what they were looking for. Implementing this proposal would also break sorting extension search results by the settings order numbers given by the extension author in their extension's file. I noticed that the issue of having to scroll down to find a keyword match is made worse when the Settings editor is "small", such as when I restore/shrink the VS Code window. Screenreader users might also have to tab down more search results to get to the one they want. Feel free to upvote the proposal if you'd like to see it implemented, or downvote it if you'd like the settings search results ordering to remain the way it currently is. You're also welcome to comment on this issue with alternative suggestions for how the search results should be shown within the Settings editor.