jiebi/CodeConvo huggingface dataset:
It is possible with VSCode to follow a path printed in the terminal. When that path also contains the line and column number in the format ( ≙ line number; ≙ column number), VSCode currently doesn't interpret it completely and therefore doesn't also jump to the line/column in the opened file. Example: ` This path format indicates the path to the file but also the line (49) and column (46) number. Ctrl + clicking this path currently in VSCode will open the file but not jump to the line or the column. As this format is used by many linters and compilers (e.g. SASS), it would be a very useful and time-saving feature.
Code link: I think here we'd want to require the exact (num)(colon)(num) to prevent problems with (link) (number) (text)
nice feature for many front end build tools.
I PR for this.
When updating cell metadata for a cell, users call which provides a function to alter the metadata of a cell. This uses defined in . When is called, the CellEditType is marked as , resulting in the metadata of the cell only being updated with the passed in data, rather than fully replaced. This makes it difficult to determine how to remove fields from a cell's metadata, a change needed for fixing . This can be worked around in this situation by setting the field to null. However, if a user calls , it appears that the functionality is a full replacement of initial metadata. There is a slight inconsistency here between the functionality of the two functions. Couple initial ideas: better document to reflect the behavior of . Add in a line stating that this is an iterative change, only altering the fields passed into this function - revise the functionality of either updateCell or updateNotebook metadata functions to align their behavior. This seems dangerous as it could likely break features leveraging this api. deprecate these functions, and rewrite two new ones with clearer functionality and documentation, based on updated needs from the notebook and jupyter teams
Analyzed all extensions using this API and most of them are already doing the right thing: clone the existing metadata, apply the change, and then call the API to update. However there are a few extensions didn't do so: there is one place where the metadata is not updated properly: PR . cc
<!-- 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!
what is the best way to verify this?
It's a bit complex I would love either or to help verify.
<!-- 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. --The [NPM support for VS Code built-in extension][extension] (which automatically detects NPM scripts and provides a UI to run them in the sidebar) has an settting. Currently, this setting only supports the options or . This means it won't work with the [pnpm package manager][pnpm]. Adding a option would be really helpful to users who use pnpm rather than npm or yarn. Both [vscode-eslint][] and [typescript-tslint-plugin][] also already support using pnpm as the preferred Node package manager. I personally use pnpm because its reduced disk space/bandwidth footprint and its architecture both work better for me. I've experimented with just overwriting the value in with , and ignoring the warning from the linter. This seems to work (on macOS), so I'm guessing it might be as simple as adding to the array here: I just don't understand the extensions well enough to be sure that's correct / enough to properly add pnpm. [extension]: [pnpm]: [vscode-eslint]: [typescript-tslint-plugin]: [source]:
uses quick chat and has found that going between the input and the response is cumbersome because of our underlying list structure. This is in particular an issue because we now have many hyperlinked tab stops. ! We should provide a way to go between the input and the focused response. AFAICT, there is not a way to do this. Pressing seems to focus the input (unexpectedly), but there's no way to get back to the response. Thoughts?
Makes sense. Probably just need to handle the keybindings better
these probably just need logic for QC
Tyler figured out that there is a way to do this, but it's in the reverse direction from what one might expect based on tab order. Use to focus the input and to focus the last response.
Talked to JooYoung and it's fine to have these reversed, we'll want to be sure that using doesn't still focus the input box.
working afaict - and for response -input and vice versa, tab works fine as well
<!-- Do Not Delete This! bugreporttemplate --<!-- 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.44.1 OS Version: Linux 5.6.4-arch1-1 SMP PREEMPT x86_64 GNU/Linux Steps to Reproduce: a symbolic link to the VSCode starting script with a space in the name. For example: "My VSCode" from the terminal Error is printed to the terminal: All in the starting script () should be enclosed in double quotes to avoid this error. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
I can take this!
great!
<!-- 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: Latest OS Version: Browser Steps to Reproduce: 'Cancel while enumerating through children' test case up above 'Root element should return children' (or use a test runner which randomized order. the test and notice that it fails. Notice how other variables in the same test use the method to make the test cases independent of each other.
<!-- Do Not Delete This! bugreporttemplate --<!-- 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: OS Version: Steps to Reproduce: Jupyter extension all cells Ctrl+Z in a cell icon in toolbar changes to No way to recover from this. Similar to However this reverts the Notebook Metadata (instead of cell metadata). <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.542 --- <!-- score: 0.483 --<!-- potentialduplicatescomment --
Validated, works now, closing this issue
Testing a file +enter to run cell in interactive window window GitHub Copilot classic installed and signed in something into the input box and ctrl+enter, this opens a third editor group with multiple synthesized Copilot solutions (feature from GitHub Copilot) close that editor :bug: now there is an empty third editor group which really shouldn't happen AFAIK, also there is screen cheese, it shouldn't really be possible for Copilot to cause this kind of layout issue <img width="1256" alt="image" src=""<img width="1245" alt="image" src=""
I assigned you for grid layout and I assigned you for editor layout, please feel free to unassign if this isn't relevant to you
empty editor groups are not a bug per-se, if you configure , groups will remain open when the last editor closes. Also, empty groups can explicitly be created, e.g. via . However, the fact that you cannot get rid of the empty group when you press the X button sounds like an issue to me. When you try to close, is there anything printed to the console?
Ohhhhhhhhhhh good bug! There is definitely splitview/gridview breakage here.
Wait. I could repro once... but not anymore. Can you still repro?
Yes I reproed twice
I cannot see anything in logs when clicking on the X unfortunately (fwiw, I do not have that setting configured) When I repro this, here's what's in the log (this happens right after closing the last editor in a group that results in the group not also being closed)
I wonder if this could possibly be a regression from the auto-sizing feature you did?
We just need to be able to repro on demand so we can attempt to repro on a version before my changes to confirm this. But I can't seem to repro no more. Can you ?
I cannot reproduce this, I never get an empty editor group. This is with fresh user data dir and extensions dir.
if you have a reliable repro that you can share, including your settings if any. Here is what I do: !
I did some more messing around and was able to repro a similar problem ! <details</details
OK, I have a trivial and consistent repro. TLDR it looks like the interactive window does not play nice with split view.
an interactive window (you can even do this with the Jupyter: Create Interactive Window command) the Settings UI the Settings UI onto the right of the interactive window :bug: the split view is very unhappy Logs <details</details
This also repros for notebooks opened in the second group Right click a .ipynb file -open to the side open another editor and drag it to the right side of the first
Oh wow. So it looks like the call to throws an exception when done in the interactive window and that means the Grid will indeed be unhappy!
for surrounding some of the calls with .
Arguably, the grid/splitview should also protect itself...
Yeah, maybe. There could be other cases.
I can't repro any of these now but it would probably help for to verify too
I still do not have a functional cursor/trackpad so cannot drag/drop maybe you can verify?
Verified it's working great
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes (all extensions other than the reproduction extension) <!-- 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.78.2 OS Version: macOS 12.5.1 Over at the Tailwind CSS IntelliSense repo we are seeing multiple reports of issues with colour decorators since the release of v1.78. Some are related to the new setting which I think is a separate issue, but we are also seeing an issue where document colour requests are not being sent to the language server at all ( is in this case). I was able to create a small reproduction based on the LSP extension sample. Please see below. Steps to Reproduce: instructions from reproduction readme: When the same project is opened in v1.76.2, the count is logged repeatedly when editing the document.
Thanks a lot for the great steps to reproduce. I pushed a fix for the issue.
VS Code does not report errors in , and then silently drops the ball without telling the user. This is particularly annoying since some things might continue working, while others mysteriously stop. Errors in come in two flavours – actual syntactical errors, but also unrecognized new properties. In particular the latter is annoying, for example when TypeScript adds new features such as (see ). My suggestion would be to at least visibly and loudly report this, but preferably be more lenient about what's accepted (e.g. unrecognized properties).
FYI
+1 I had a similar issue (non existing compiler option) and I didn't get why my configured target=es6 got not accepted. Interestingly, it worked when compiling over command line but it failed when compiling over tsserver. See also the TS compiler code. Maybe one could get that error from tsserver back to VS code?
+1 I've just had a similar issue that I've spent 3 hours working through. Adding a new typescript 2 option such as "noUnusedParameters" caused vscode to reference not , making some of my code have errors in the editor, but not when built! I've worked around by having a different that I used for building with.
See
Does this issue occur when all extensions are disabled?: Yes Version: 1.77.0-insider (Universal) Commit: Date: 2023-03-17T21:00:47.582Z Electron: 19.1.11 Chromium: 102.0.5005.196 16.14.2 V8: 10.2.154.26-electron.0 OS: Darwin arm64 20.6.0 Sandboxed: Yes Steps to Reproduce: Execute the following extension example: a text file and select a completion item , type , and select a completion item results are different https://user-
This is specific to additional edits that are after and on the same line as the suggestion. The newly typed characters (type after return the list of item and before selecting one) aren't taken into account
<!-- 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.73.1 OS Version: macOS 13.0.1 Steps to Reproduce: a VS Code Remote SSH session a .hbs file selected language at the bottom right is "Plain Text" and when clicking it, Handlebars is not available in the list
The extension thinks it needs to be installed on the SSH remote: ! On it's own the handlebars extension doesn't need to be installed on the SSH remote, but the HTML languages features extension appears to be pulling it in with . It seems like this is related to The problem is easily fixed by adding this to handlebars: But that might break
Nice! Thanks for figuring this out! I initially believed this was a feature request to add a builtin handlebars grammar.
The handlebars could run on the renderer, but because it defines it is deduced to run on workspace. If were an internal contribution point, we could define a , but we don't have a way for contributions to declare a contribution point (a contribution contribution) So these are the possible solutions "extensionKind": "ui", "workspace"] as suggests as it overwrites the detected extension kinds Implement a contribution contribution point include the extension also in the server build I go with the first one for now. speak up if you disagree
<!-- 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.93.0-insider Commit: Date: 2024-08-29T05:04:03.909Z Electron: 30.4.0 ElectronBuildId: Chromium: 124.0.6367.243 20.15.1 V8: 12.4.254.20-electron.0 OS: Linux x64 6.9.3--generic Steps to Reproduce: a few editor groups in seemingly any split configuration one for text input or otherwise run to type: no result, as no editor has focus any more. This is especially frustrating when some of your other keyboard shortcuts rely on the editorFocus context, as they become unusable after using this feature.
In case this takes a while to fix, anyone looking for a workaround can rebind their preferred shortcut to automatically refocus the editor and then "move" the cursor to ensure if another window has now covered your cursor, the editor scrolls to reveal it again (also respecting scrolloff setting).
<!-- 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!
/verified
I see this when starting the panel chat voice action in dev tools. An easy way to know when this reproduces is to enable the audio cue, which then plays forever.
<!-- 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!
<!-- 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. --- 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. --- Microsoft Windows 11 Pro 10.0. N/A Build Not sure if this is intended behavior or not but I think if I use the button it should create and show the repository. If is set to , the repository is actually created but nothing is shown in VsCode I understand that this option is for auto-detect and it's kind of logical, but should it affect the action? !
thank you very much for filing this issue. Setting to disables repository detection independent whether it already exists or it has been created using VS Code. While this is the intended behaviour, I agree that we could probably make this experience better.
<!-- 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.81.0 OS Version: Windows_NT x64 10.0. Steps to Reproduce: In , set the content to then start VS Code with shell integration enabled and use Windows PowerShell. This bug will occur: The use of at: Needs to be guarded for Windows PowerShell (where it doesn't exist). /cc
Sharing from my profile:
Issue Type: <bBug</bAfter updating to 1.43.0, when VSCode relaunched, it brought up around 80 editor windows from old projects I hadn't opened in quite some time. (spooky workspace necromancy) Perhaps obviously this made my computer behave quite poorly. I tried adding "window.restoreWindows": "none" to my with another text editor, but it didn't seem to be respected (might be my fault somehow). Note that it had been on "folders" previously, in case that helps. I also tried to muck about with file. VSCode seemed to ignore my changes to it (probably not a bug -- I was desparate and dunno how this file works), but I do have a backup of a from right after this happened. It shows all the windows it will try to open when launching, and maybe other stuff. I guess the system info probably has more PII anyway. I dunno how much this helps but: I think the main common feature of the workspaces it resurrected seemed to be that they had open files with unsaved changes -- but these are also the ones which can't be closed without additional UI confirmation, and I did try a couple things to close all windows in bulk (none seemed to work, but maybe I just didn't notice?) Relaunching without extensions also didn't help, but that doesn't mean this wasn't caused by an extension in the first place or somethign. I have more than is probably reasonable installed. That said, it happening immediately after updating to 1.43.0 makes me think it's vscode and not an extension. Anyway, ultimately I just bit the bullet and closed them manually -- VSCode would be usable for about 20 seconds after starting, during which time I could close a few before too many were restored and everything got too slow. So i just did this, quit, and repeated many times until there were no more left (this actually took a couple goes -- even when I'd get down to none left, save, and reopen, it would find some new ones to bring back... Guessing these just didn't make the cut for being restored the previous time, or something) P.S. it would be nice if there were a command line argument to launch without reopening anything. P.P.S.
In case it isn't clear: I've been using , , and somewhat interchangably here, just so you don't think I'm being precise about which I use when. VS Code version: Code 1.43.0 (, 2020-03-09T19:34:44.548Z) OS version: Darwin x64 18.7.0 <details<summarySystem Info</summary </details<details<summaryExtensions (55)</summaryExtensionVersion ------ code-gnu-global0.2.2 better-toml0.3.2 glsl-canvas0.2.8 bracket-pair-colorizer-20.0.29 dart-code3.8.1 xml2.5.0 scopes0.45.0 gitlens10.2.1 vscode-html-css0.2.3 tslint1.0.44 vsc-material-theme32.5.0 vsc-material-theme-icons1.1.4 prettier-vscode3.20.0 vscode-test-explorer2.17.0 vscode-peacock3.6.0 language-haskell2.7.0 center-editor-window2.3.0 chat0.31.0 restructuredtext120.0.0 fish-ide0.4.0 regionfolder1.0.8 Kotlin1.7.1 rust-analyzer0.1.