jiebi/CodeConvo huggingface dataset:
Lisp0.1.10 ninja-syntax1.0.0 prettify-json0.0.3 vscode-json51.0.0 vscode-docker1.0.0 csharp1.21.13 sublime-keybindings4.0.6 vscode-typescript-tslint-plugin1.2.3 vsliveshare1.0.1711 vsliveshare-audio0.1.80 vsliveshare-pack0.3.4 debugger-for-chrome4.12.6 idl0.3.1 autotrim1.0.6 proto0.0.2 material-icon-theme4.0.1 polacode0.3.4 tcl0.1.0 crates0.4.7 trailing-spaces0.3.1 vscode-scheme0.4.0 fish-vscode0.2.1 shader1.1.4 rewrap1.9.1 shellcheck0.9.0 org-mode0.5.0 cmake0.0.17 vscode-lldb1.5.0 vscode-icons10.0.0 material-theme3.2.3 vscode-open-in-github1.3.6 tslint-snippets1.1.0 (11 theme extensions excluded) </details<!-- generated by issue reporter --
FWIW this does seem to be respected now and I haven't changed anything, maybe indicating that it was being ignored for some reason during all this? Not sure if this is important, but worth noting I guess.
Hit the same issue here, VSCode opened up a few hundred projects after upgrading and my mac nearly fell over:
Yeah, I expected this to happen. Works now "correctly" after pushed This is expected hot exit behaviour to restore workspaces that have backed up files.
Hit this last night as well and it completely froze my machine up for minutes opening at least 40 windows. I get why this is an expected fix for a bug, but I it made my computer totally unresponsive and probably could have used a more progressive one-time rollout.
So it looks like this was a regression in 1.42 () and it's now fixed as it's designed. It's designed this way so that by default, backups don't go "missing" by accidentally closing window(s) and forgetting which one had your notes in it.
I can attest to the fact that it's awful when many windows unexpectedly restore as it happened to me when testing settings sync. I'm not sure what the right recovery fix is but you can workaround this in the meantime by setting in your . To go back you would need to either delete the backup files manually ( from the 's folder) or open the workspaces and close unsaved files.
Just to clarify, for anyone coming to this thread who's hosed with 40+ windows, it sounds like what you're saying is the workaround is set to so that we don't have to go through a ton of different "do you want to save this?" prompts when we try to close every window. set to (or another reasonable setting) so that VS Code doesn't try to open a ton of windows for every workspace with unsaved files. delete the unsaved buffers manually until things are bearable again. Is that the recommendation?
Is all I needed to stop the window tsunami.
if you just set you should be fine if you then open a new folder () and then close the window. This is actually how I've always used hot exit and recommend it if you haven't tried, it takes the rails off and was meant so that you can close windows arbitrarily even on macOS as well as not restoring all windows with backups whenever VS Code gets launched. If you want to go back to , deleting the buffers manually after reviewing is probably the best way to go.
I'm struggling to find a way to properly fix this for users without just changing the behavior something since this change in behavior looks to have been in . Maybe some restriction on the maximum number of windows that can be opened at once, with a dialog if it's over 5 or something? do you know what the behavior was before? seems to add folders to a the active workspace, does this mean all workspaces with folders were getting restored into a single window, or did they get dropped somehow?
I am quite sure we opened 1 window per backup directory with backups. So ended up always restoring every window that has backups. We decided with this approach to ensure we always bring back dirty files into their windows independent from any setting (other than the hot exit one at least). Btw untitled workspaces behave exactly the same for the same reasons because they may contain setting changes that are unsaved.
I think you're describing the designed behavior, I mean to ask about the behavior to 1.43 so that it's clear how having caused the backups to behave and why backups stacked up not getting restored (was this because they weren't being saved to anymore?).
I think can comment if there was some intention behind the change or just an oversight. To be clear: I would never expect a folder with backups to be to a workspace to turn it into a multi-root workspace.
One thing might be considered, as discussed with in Gitter, is to limit the number of windows/workspaces to be restored upon start, such as 10 at most, which might relieve this "correction".
We decided to fix this by reverting the change and no longer restore the folders with unsaved content. That was the behavior from 1.32 to 1.42 and as we didn't get any complaints, this seems to be practical. You can always open these folders from the recent menu, and unsaved content is restored. I created as a followup issue for the next milestone. We plan to also no longer restore workspaces (except unsaved/untitled workspaces) and we will add more information to the recent menu to show which folders/workspaces have unsaved content.
To verify: set open 2 windows, each opened on a folder. Make a unsaved change or add a untitled file with content close both windows. There should be no questions asked, exit VSCode open VSCode on an other folder (). Only one window should appear
When a user opens a file extension that does not have a specific recommendation tied to it, we show the general notification that points users to the marketplace. This has the following flaws: Most popular file types are already covered by specific extensions, so what gets left in this experience is leftovers For most of the extensions there is no good extension to handle this experience. Thus opening the Extension page does not provide value This is adding un-needed pings to the Marketplace service Also we had a bug that this feature was not available in stable and only 3 users found it is not there Would love for us to get some telemetry on this actions to see if this is actually bringing value to users. If not, we should either: Remove this flow completely Have a pre-defined set of file extensions for which we show this. Checking with tags seems to be very faulty. In my example below there is not an extension that helps with PowerPoint files. !
Only of these notifications end up with users clicking on Search Marketplace ! When it is actually clicked here are the top extensions ! Thus I suggest that we: Remove this dialog Add explicit extension recommendation for and . Since those seem to be missing. what do you think?
Sounds good to me
Great. Ok, you remove the dialog when you find time, I will add the recommendations for csv and pdf. Or if you go on vacation, I can also remove the dialog. I am working in August. Thanks
Feel free to remove it in August, otherwise I can also do it in September. Here it is
To verify: a file with some strange extension. For example -make sure no notification shows up a .py file or .go file. Make sure you get an extension recommendation for specific python / go extensions
<!-- Please read our Rules of Conduct: --<!-- 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.41.1 OS Version: Windows 10 Steps to Reproduce: the "Explorer" view (e.g. with Ctrl+B) a file from the Windows Explorer to drop it in the Explorer icon in vscode. explorer does not automatically open, which would be somewhat helpful, in order to be able to drop the file in the folder of your choice directly. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
This is a fair feature request for the that on dragOver the corresponding view would get open. I think this feature reuqest makes sense in general, since in the future we might want to drag and drop views between containers, and then the corresponding container should expand. Thus also assigning to
this is a regression though. Testing I can move a file from the desktop over the (collapsed) activity bar and views expand properly and focus depending on which view is hovered. This was very useful to drag images to for writing release notes. Can we bring it back?
Re-labeled it then, and assigned to Janaury so we try to fix it this milestone. hope that makes sense.
Thanks a lot for the fix
! 'void' should not as column num Version: 1.70.0-insider (user setup) Commit: Date: 2022-07-26T05:16:55.337Z Electron: 18.3.5 Chromium: 100.0.4896.160 16.13.2 V8: 10.0.139.17-electron.0 OS: Windows_NT x64 10.0.
Your Insiders is outdated. Please update and retest.
Version: 1.71.0-insider (user setup) Commit: Date: 2022-08-12T05:17:00.323Z Electron: 19.0.11 Chromium: 102.0.5005.167 16.14.2 V8: 10.2.154.15-electron.0 OS: Windows_NT x64 10.0. Sandboxed: Yes still have problem
sorry for mistake close
Tricky edge case, perhaps we should parse the col/row and remove col if invalid and col+row if they're both invalid?
<!-- 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.1 (system setup) Commit: Date: 2023-05-04T09:48:08.683Z Electron: 22.5.1 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: WindowsNT x64 10.0. Sandboxed: No Steps to Reproduce: a workspace at a UNC path that isn't set in security.allowedUNCHosts. "Yes" when prompted to temporarily allow working from that host. changes to one or more files without_ saving them. VSCode without closing the workspace (may require specific settings to automatically re-open the previous workspace). time, click the "Learn More" button when prompted to allow working from that host. Note that any unsaved editors remain, but the rest of the workspace is not loaded as though the user clicked the "No" button. I'd argue that "Learn More" doesn't constitute a decision from the user and shouldn't proceed as though it was. Depending on the nature of the changes, this may cause a problem for safely saving those changes because if the user tries to re-open the workspace, they are asked to either save or close these orphaned editors. Perhaps a link among the text in the dialogue box would be more appropriate than a button which closes the box.
I agree that the dialog should not close and/or make a decision when you click "Learn More". Unfortunately the dialog closes when you press that button, so best I can do is to open it again asking the same question.
Markdown file on Plain Text on startup: ! Same with TS in another window: ! Reproduces by reloading the window. Not sure who the right person is for this Version: 1.93.0-insider (user setup) Commit: Date: 2024-08-08T05:03:51.428Z Electron: 30.1.2 ElectronBuildId: Chromium: 124.0.6367.243 20.14.0 V8: 12.4.254.20-electron.0 OS: Windows_NT x64 10.0.
On it
<!-- 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. --Type: Bug Missing pricing parameter in extension manifest. The attribute is not included in the and so does not show up in IntelliSense. Related docs issue: I'm working on the fix. FYI: <!-- 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. --
<!-- 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 The behavior was correct few weeks ago. <!-- 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.65.0 Validation : Date : 2022-03-02T11:12:36.248Z Electron : 13.5.2 Chromium: 91.0.4472.164 : 14.16.0 V8 : 9.1.269.39-electron.0 Système d’exploitation : Linux x64 5.16.11-100.fc34.x86_64 Steps to Reproduce: an integrated terminal and type the following command : , alt + click on the printed link browser is open with url , but it should be opened with url ! Working test on native terminal : a native linux terminal (for my DE, it is gnome-terminal with zsh) the following command : , ctrl + click on the printed link browser is open with url , as this is the correct expected behavior !
Looks like we're passing the right thing to the opener service !
I can repro this with: I can copy and paste that URL into a browser and it will work. I can run the same code in regular terminal and it will work. It doesn't work when I click on the link from w/in the vscode terminal.
This has come up before where it was closed by design, originally I don't think it was possible to open a link like this because opener service always works on uris and they always encode like this. I notice though that the editor properly retains the in a link though so it should be possible now.
Okay thanks!
Thank you
Environment Details: VSCode Version : 1.24.1 OS Version : Win10 Additional Details: MAS Violated: MAS2.4.7 Repro Steps: VS Code Keyboard Shortcuts from the Settings icon on the bottom left bar. Dark+(default dark) theme and other dark themes and check the focus visibility. Actual: Keyboard focus is not clearly visible on Sort by precedence button when default dark theme is applied. Expected: Focus should be clearly visible and should be outlined by solid or dotted line. Recommendations: Refer below link which is repository of bug fixes code snippets: User Impact: User will not be able to see the focus properly. MAS Reference Attachment for Reference: ! Does this issue occur when all extensions are disabled?: Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.593 --- <!-- score: 0.523 --- <!-- score: 0.457 --<!-- potentialduplicatescomment --
Sounds like colors and contrast, also assigning to
can you clarify if this also applies to our overall focus treatment? We use the same blue outline for most of our focus treatments: ! ! !
You can use any color for emphasizing the focus but it should be clearly visible to the user on all the color themes.
Please let me know when there are any changes to be done from my side.
will do, I think I'll need to play around with the offset of the outline color (and possibly opacity).
This issue has been closed automatically because it needs more information and has not had recent activity. See also our guidelines. Happy Coding!
<!-- 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 (in docker): building and running the following dockerfile gives the following: changing the command in the docker file to gives the following: creating a non-sudo user in the docker container and running it from that works, but that leads to a headache of problems with other parts of my docker image. ideally, the fix suggested by code in the first example would solve this but it doesnt.
related to
doesn't apply to . That's an option for electron, and doesn't run electron. Just omit that argument and run the command.
omitting just makes it complain about being unexpected. no combination of arguments fixes this as far as i can tell causes causes causes causes
What code print?
i put the output of at the top of my issue, but here it is again:
would it be possible to reopen this? it seems like there is no solution based on whats been said so far
Looks like a workaround would be setting when you call . But the better solution is just to use the CLI () instead of the full desktop install. This will be fixed when the desktop install uses the native CLI as its primary entrypoint.
Works with . The is important, otherwise it will be misinterpreted.
I still get the same error: adding CANRUNAS_ROOT=1 did not make a difference.
I cannot repro, can you share the exact command you ran?
All is good, sorry, I tested against an old version!
This issue will be closed because it appears to be verified
Type: <bBug</bCC a terminal in editor area in the terminal alt+f2 to open Accessible View alt+UpArrow and alt+DownArrow to see if it moves between executed commands. Notes: alt+DownArrow unexpectedly opens a new terminal view. VS Code version: Code - Insiders 1.83.0-insider (, 2023-09-21T05:34:38.227Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (91)</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.51.0 vscode-eslint2.4.2 vscode-quick-select0.2.9 vscode-deno3.23.1 gitlens14.3.0 EditorConfig0.16.4 prettier-vscode10.1.0 vscode-google-translate1.4.13 codespaces1.15.3 copilot1.115.430 copilot-chat0.8. remotehub0.60.0 vscode-github-actions0.26.2 vscode-pull-request-github0.72.0 overleaf-workshop0.2.1 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 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.311.0 remote-ssh0.106.4 remote-ssh-edit0.86.0 remote-wsl0.81.4 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.2017 powershell2023.6.0 remote-repositories0.38.1 vscode-github-issue-notebooks0.0.129 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.4.3 quarto1.98.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.13.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.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 --
I could repro this yesterday, but it's working for me in today's insider's. Pls let me know if it's not for you.
Still does not work. Tested on Windows 11.
I had forgotten this is an issue only when the terminal is in the editor area.
<!-- 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 Does this issue occur when all extensions are disabled?: Yes/No VS Code Version: 1.77.1 OS Version: Ubuntu 22.10 Steps to Reproduce: !
The bot never kicked in, can you check that it is fixed in the latest Insiders build of VS Code?
I can confirm, it is fixed!
<!-- 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.77.3 OS Version: MacOS 13.3.1 Steps to Reproduce: Run the following commands Trust the workspace, then start the script from the "NPM Scripts" panel. The script runs, and the name of the script appears to the right of the output panel, together with a spinner showing that it's running. Now run the script again. A popup window appears saying that it's already running, and do you want to terminate or restart it (just close it without doing either). This is all expected behavior. Now (with the task running) run Cmd-Shift-P "Developer: Reload Window". The window reloads, and the script continues to run (you can tell it's the same script because it's printing its pid, and it doesn't change). The name is still in the right hand pane, but now the spinner has gone, as if vscode no longer knows that it's running. Now run the script again, and although it's already running, it starts a second copy. This is the bug. It's especially painful for "runOnOpen" tasks, because every time you reload the window (eg because an extension needs updating) they all continue to run AND a new copy of each one starts. I thought there might be another bug in the recently (since that was supposed to fix exactly this issue - ), and took a look at that.