jiebi/CodeConvo huggingface dataset:
I'd like a setting to optionally prevent deprecated things from showing up in intellisense suggestions. For example, I'd like a way to prevent from being suggested here, so that I don't use it despite a non-deprecated version being available. ! My linter can catch it, but it'd be even nicer never to see the deprecated option. There are several documentation systems that use the tag: JSDoc: TSDoc: JavaDoc: Yard (for Ruby): Other systems use different, similar tags. I'm not sure if this is an issue for the VSCode core, or for something language-specific.
Sorry if this is a duplicate or is already possible. There are enough issues here and questions/answers on Stack Overflow that it's hard to be confident. This issue is related:
Not showing deprecated suggestions can be implemented by individual language extensions today (not striking out but tracks that). Adding just to see this is something we want better VS Code api support for in some way Otherwise, we can track this as a feature request for js/s
I'd say this is a dupe of and it would be us adding some API flag and then allows users to configure how the suggest UX is handling that flag
/duplicate of
Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for existing issues . See also our guidelines. Happy Coding!
Okay, that makes sense. What does "js/s" mean?
is it possible to add a setting like , so I can disable it to prevent deprecated from showing up in suggestions list?
Hey any update on that?
Verify that the setting exists and that it filters deprecated elements from IntelliSense
Add support for setting the contents of files created by workspace edits My proposed would be to add a option to : For , we want to support copying images from desktop into with drag and drop. Right now we have to use the apis to create the image file Using a workspace edit would let us express the entire operation in a single , which will play more nicely with undo/redo
Looks like support for this may already exist internally: However getting a of new file data from the extension host to the main process may be tricky. We can only efficiently serialize a if it is a top level argument to an RPC call or if the entire object is wrapped in a (which has a perf cost). Open to ideas on how to handle this
I do like the and believe the cost is manageable - we don't send edits is large frequencies and of large sizes. I can take a look at this but it honestly is stretch for June - there is some debt in how workspace edits are represented on the wire and I would take this issue as a reason to clean things up
work started here: I didn't bother with or hoisting the data to the top but instead it uses quick and dirty base64 encoding. I'd suggest we go with that and see how it works out over time.
I tested on Win11 & Win10. It works as long as you start a new workbook and don't save the jupyter notebook. Once you save the notebook, your pastes of images from the clipboard will no longer be treated as inline attachments. Originally posted by in
Possibly getting overridden by a markdown file paste provider?
were you able to replicate my findings?
Reviewed this thoroughly, and found the following. All cases are performed with a screenshot copied to the clipboard, and pasting into markdown notebook cells using ctrl+v. Using Windows 11 and current insiders. With setting unsaved notebook (command pallete -new jupyuter notebook -) results in broken markdown image link pasted, broken rendering (see screenshots attached) ! ! saved notebook creates image file on disk, creates markdown image link, renders correctly. With setting unsaved notebook (command pallete -new jupyuter notebook -) results in correct inline attachment image link pasted, renders correctly saved notebook results in correct inline attachment image link pasted, renders correctly
With the above investigation, I believe this is likely an issue with markdown paste providers, assigning to take a look at this. to clarify, are you expecting the images to be created on-disk upon paste, and referenced via an image markdown link? Or are you looking for the experience, with images stored in the notebook itself. The latter can be achieved and still works properly with the setting
I prefer the later, where the images are stored in the notebook, this makes it easier to share with others in these scenarios. This used to be working and then stopped working in the build I noted in the original question refenced, but I just tested in the latest build and it is back to working as expected, so must have been a bug that has now been fixed: The version I just tested with is updated now and it is working as expected with the Version: 1.83.1 (system setup) Commit: Date: 2023-10-10T23:48:05.904Z Electron: 25.8.4 ElectronBuildId: Chromium: 114.0.5735.289 18.15.0 V8: 11.4.183.29-electron.0 OS: Windows_NT x64 10.0.
Works fine for me too with the default settings. Will disable pasting into untitled notebooks with the setting off
<!-- 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.86.2 OS Version: Not relevant Steps to Reproduce: a new file <kbdCTRL</kbd<kbdSHIFT</kbd<kbdP</kbdand choose YAML <kbdCTRL</kbd<kbdS</kbdthat the extension is ! YAML's documentation recommends the extension: see
In VS Code we able to push git repos to different places with "git push to" and choosing the remote server to push. I'll be nice if we can be able to choose from the repo to pull files, and manage the default remote, today the first remote repo is the default isn't possible to change that via VS Code
Thanks for all your contributions. You all created a PR to solve the same issue; all in a surprisingly similar way. I wanted to keep the record of all your work so I did an octopus merge with git, thus keeping your names in history. Thanks once again!
Issue Type: <bBug</bsearch.maxResults to a value larger than some text in file which may have results more than "Open in editor" in search panel search editor shows " results - 1 file The result set only contains a subset of all matches. Be more specific in your search to narrow down the results." and only results shown in search editor VS Code version: Code 1.58.0 (, 2021-07-08T06:54:55.083Z) OS version: Windows_NT x64 10.0. Restricted Mode: Yes Remote OS version: Linux x64 4.15.0-136-generic <details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.468 --- <!-- score: 0.45 --<!-- potentialduplicatescomment --
Accidentally already created a walkthrough of how to resolve this in so I'll post it here: To reproduce, set the max results setting to some larger value, and run a search in the search editor which has more results than the value: ! ! Access search editor with: ! You can start by changing the limit passed here to read from the Then, you should add a way for the search to be re run with no limit. See what happens in the search from the sidebar, whose code is here: for how to make that change.
Hello, , I would like to work on this issue. As-is: Search Editor has maxResults fixed to To-Be: Should use a maxResult value from configureationService and with no limit if value is null Am I understading the issue correctly?
yes that is correct. Thanks!
Hey have you started working on this? If not, I'm interested on picking it up.
I've been busy so I have not done much, so you can pick it up. I realized it requires more time than I previously expected. As far as I see, making search editor to rerun the search results with polling like the search view requires some work...
It is by design that the search editor does not stream results, this causes undesirable behavior in an editor context when you may be in the process of manipulating the results. For this ticket simply respecting the setting is sufficient.
Type: <bBug</bHow to reproduce the issue: and Run the Extension the , and then the pane. Use the dropdown and select the Dynamic Configuration Provider . With the checked out branch, it will show the quick pick options for Option 1 - 3, but will not show a quick pick for the resolved configurations. This seems to work for , but not Expected: ! Actual: ! VS Code version: Code 1.77.3 (, 2023-04-12T09:16:02.548Z) OS version: WindowsNT x64 10.0. Modes: Sandboxed: No <details<summarySystem Info</summary </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
Thanks for creating this issue! It looks like you may be using an old version of VS Code, the latest stable release is 1.78.0. Please try upgrading to the latest version and checking whether this issue remains. Happy Coding!
I've updated to: and it still reproduces.
for prioritization help as per email thread
Sent a PR for this. But what is the inner quickpick? I'm a little unsure about the approach, I don't think we expect a provider to include some UI. Your extension doesn't own the UI in this flow- you are just implementing a provider method which will be invoked at different times, expected to return a list of configs. It might make sense in one situation to show the quick pick, but we could make changes in vscode to call your provider at a different time where it would be unexpected to have a quick pick pop up. And, any extension can implement a config provider for your debug type. So for example, multiple extensions could all be showing their own UI in this scenario. However, from memory, I think the Python debug extension might already have a similar multi-step picker UI for a scenario like this.
Testing When my cursor isn't inside of a conflict, this command does nothing. Should it only be visible in the quickpick when it does something? Or should there be an error message when you try to run it but it doesn't do anything? Same with the "Toggle Current Conflict from Right". <img width="549" alt="image" src="https://user-"
I fear if we hide it when there is nothing to toggle, users won't discover that there is a (keybindable) command for this functionality. How did you find this command? Was your cursor in a conflicting region?
It wasn't in a conflicting region at the time
Let's show an error message if this command does not do anything.
If I run the toggle command in an invalid region, I get a notification, which is good. But, if I then toggle a valid region after, the notification still stays on the screen for a while. Can the notification be hidden when the user toggles a valid region?
Can notifications be removed? I thought that is not possible. Also, I think this use-case is quite rare. The notification is just to teach that you should be in a conflict.
<!-- 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?: 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: Current OS Version: Web issue only (repro) The repro steps for this are entering via the VS Code for education route for Steps to Reproduce: to with MS credentials the courses list, select the 'Getting Started' course should be launched with our extension and course loaded this point you can already see the errors in the dev console to see the specific issue select the "Coding Challenge" section ! In this section a code editor file should have been opened up in the editor, but it is missing. We see the following in the dev console when the course is loaded. I don't have a full bead on exactly what is happening here, but we have not been changing the extension this sprint, so it seems to be a recent new issue that is just in insiders and not in stable (which works fine still and does not have the errors). ! I took a look at recent issues and this one comment appeared here that might be related?
Adding the log file here.
For comparison, this is the same scenario in stable ! And insiders: ! Note the errors, plus terminal and editor have not opened up.
Hope you don't mind a direct ping here, but I think you might have context both on the VS Code for Education route and possibly on the issue above?
this is related to Looks like we may need to add to the iframe content security policy. Taking a look at this now cc
I was able to verify the issue has been addressed in latest insiders following the steps from OP. please also confirm on your end. Thanks!
Looks good now. Thanks for the quick fix!
From Probably a regression from making aarch64-linux ripgrep build statically compiled to fix We might need to dynamically compile ripgrep instead of using musl, and find a container to compile it in. related // cc
Looks like jemalloc just needs to be configured with to support 16K page size. This can be achieved by setting the environment variable: (16K page size) Or to support 64K page size as well: (64K page size) In either case, it'd still work for 4K/16K(/64K) page sizes.
Do we have any good news on this? I found the similar thing happened before on other application like , probably we can use the same approach to solve this one?
Any update on this issue ?
Temporary Workaround: To address the issue until it is fixed, follow these steps: Install ripgrep and obtain its path. For Rocky Linux or any RHEL-based Linux distribution, run the following command with root privileges: For Ubuntu, use the following command: Alternatively, you can install ripgrep using Cargo: Verify the installation and retrieve the path by running: Replace the broken rg with a symlink by executing the following script. Please note that you should remove the echo commands to commit the changes: This workaround should help resolve the issue temporarily.
This should be fixed in tomorrow's VS Code Insiders. Please try it out and let me know if it works for you!
I tried but it seems not fixed or not included the fix. execute from the remote server(aarch64) and got <jemalloc: Unsupported system page size <jemalloc: Unsupported system page size memory allocation of 5 bytes failed find: ‘.vscode-server-insiders/bin//nodemodules/ terminated by signal 6 (after resetting the remote environment by deleting .vscode-server-insiders folder on the remote, and vscode reloaded. - 'Developer: Reload Window')
Are you running 16K page size or 64K?
I got $ getconf PAGESIZE on the aarch64 remote (Rocky Linux 8, aws r7g instance/Graviton3 processors).
Meanwhile, executing the same command above on x86-64 remote, I got the normal rg help print out as like error: The following required arguments were not provided: and correcting the hand typed typo above of vscode insider version info Version: 1.79.0-insider (user setup) Commit: Date: 2023-05-19T20:39:14.598Z Electron: 22.5.2 Chromium: 108.0.5359.215 16.17.1 V8: 10.8.168.25-electron.0 OS: WindowsNT x64 10.0.
Hmm ok. I tried setting the env variable to increase max page size for jemalloc, but it seems to not be working. I'll try another approach.
If you let me know what you are attempting, I can also try out some stuff. Page size here is
Is this fixed in the latest release version of VScode? I just check on my arm64 container but it seems not working. VScode Version: 1.79.0 (Universal)
Same with Switched to newest insider build. . Problem not solved. Went to server, killed and deleted . Tried again to bootstrap. Problem is still NOT resolved. Search is still limited to open files.
!
Here is some useful link detailing what I think is the problem. Not sure if it is resolved by now. But if info from the discussion is current, I think you will have to either compile on the target system, or ship different precompiled versions of binary and select the correct one depending on the system specs (see ).
We do cross-compile for different systems for ripgrep I'll have to take another look.
So, my interpretation is, that the page-size is hard-coded into jemalloc. When the system page size at runtime differs from the one it is compiled for, it will fail. In other words, the one shipped right now fails out of the box: From your linked repo, I understand that you now focus on 16k page size. That would also not help me (if my suspicion is right), as my system's page size is: 64k
: Temporary fix. Bootstrap on target ARM system. You should have a directory called now. That is where the vscode server lives.
Download and compile : Replace binary deployed by with custom compiled version. Now search should work as expected.
can you check if the following runs fine on your aarch64 setup ? The build is generated from to use 64k for jemalloc.
Thanks built from source works for me!
can any of you verify this:
I untar-ed the file and the binary 'rg' is working good with remote search. (I sym-linked it with vscode 1.79)
<!-- 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!
I can confirm it is fixed with the vscode insider downloaded a minute ago of (assume the commit hash changed since)
thanks so much for checking!
!
Caused by I caused when I fixed an issue when there are multiple text editors open with the same uri with comments. When I tried to fix I made it so when extensions call and pass in for the comments, we always expand the reply editor, resulting in the bad behavior above. I took a quick look, and it seems very common for extensions to pass in for the comments and then immediately set them.
To verify: Check out PR with comments that you left Reload to make sure there's not state left over from when you left the comments Open the file with the comments and click on the comment icon in the comment bar to expand a comment that you left Verify that the reply input button is collapsed and isn't a big empty rectangle.
Works great -verified.
<!-- UNABLETOLOCATECOMMITMESSAGE repo --Issue marked as unreleased but unable to locate closing commit in repo history. If this was closed in a separate repo you can add the label directly, or comment .
<!-- UNABLETOLOCATECOMMITMESSAGE --Issue marked as unreleased but unable to locate closing commit in issue timeline. You can manually reference a commit by commenting , or directly add the label if you know this has already been releaased
Code, search for "bracket pair colorizer" how it is nicely rendered as deprecated on install -notice dialog The dialog should offer a third button to configure built-in settings instead. Same if an extension had an alternative extension. Example: ! fyi
I assume you want the extra button to replicate this link in the hover tip, right? ! As an aside, any doc yet about how an extension gets tagged as deprecated?
yes, a button that will replicate that behaviour correct. No docs yet written. I plan to add them soon. The process is to write an email to us or to ping us on GitHub. In the future we will have a more straightforward approach when MP adds UI.
I feel, the third option would be a general options like More Information... clicking on this shall open the extension editor. This will be consistent and useful so that user will get enough info before taking an action
"More Information..." might work, but in order to have one less hop we could render: "Install EXTENSION_NAME Instead" "Enable Native Settings Instead" That would just do the action right straight away. I am not sure if those button names are too long. So just a suggestion. Whatever you prefer...
Yah I see your point, but going to extension editor gives user more information and an opportunity to look at the alternative extension before installing. And also I do not like that this button changes with extension. More Information... would be consistent.
That's fair. We can start with your proposal and see how it goes. My only concern with "More Information" is that the user might think it is more information about the deprecation. While we actually want to guide the user to a solution. So it is something like "More about the alternative". I am not sure if there is a good button label to represent this.
<img width="308" alt="image (1)" src="https://user-"
Changed the second button as follows ! !
Awesome!!
<!-- 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.75.1 OS Version: Windows 11 Steps to Reproduce: a link in the terminal of the form the link would be automatically detected correctly and made clickable (although in the debug tab, by contrast, it was not detected properly). version 1.75.0, the link detection wrongly terminates at the so the link cannot be easily clicked to open it. I appreciate that you can never please all the people all the time with URL guessing, but I thought it was worth mentioning given that it used to work fine, and to be fair all the characters , and are standard normal URL code points and always have been.
Can repro after, not before: !
This is actually a regression in monaco's link detection which the terminal leverages for uris: 74: <img width="259" alt="image" src="https://user-"75: ! So this was unrelated to the recent terminal link improvements which focused on file detection
introduced this change to fix
Commas are used pretty often in certain links, not sure how advanced the detection is but it could be improved by only treating it as a separator if after a / or if the word before has a period?
GitHub also doesn't split at comma: , I'd probably revert the fix, but I'm fine with either. Up to you
This issue doesn't just affect the links in the terminal. It also applies to , and files (and maybe more).