jiebi/CodeConvo huggingface dataset:
Code change:
private _password = false; private _prompt: string | undefined; <del> private _validationMessage: string | undefined; private _validationMessage2: string | InputBoxValidationMessage | undefined; </del> <ins> private _validationMessage: string | InputBoxValidationMessage | undefined; </ins> <del> constructor(private readonly extension: IExtensionDescription, onDispose: () => void) { </del> <ins> constructor(extension: IExtensionDescription, onDispose: () => void) { </ins> super(extension.identifier, onDispose); this.update({ type: 'inputBox' }); }

Related discussion:
text: <!-- 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. --We already have this feature in Core: where you can return where . Truth be told, this already works in API today though it's not officially a part of the API today (so it could change at any moment). For example, I can do: <img width="738" alt="image" src="https://user-"with it goes from: to it goes from: to
ref
Created a TPI so moving this to April for Finalization.
Code change:
} for (let suggestion of container.suggestions) { if (!options.kindFilter.has(suggestion.kind)) { <ins> // skip if not showing deprecated suggestions if (!options.showDeprecated && suggestion?.tags?.includes(modes.CompletionItemTag.Deprecated)) { continue; } </ins> // fill in default range when missing if (!suggestion.range) { suggestion.range = defaultRange;

Related discussion:
text: 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
Code change:
integrity sha512-OkTL9umf+He2DZkUq8f8J9of7yL6RJKI24dVITBmNfZBmri9zYZQrKkuXiKhyfPSu8tUhnVBB1iKXevvnlR4Ww== katex@^0.16.2: <del> version "0.16.3" resolved "https://registry.yarnpkg.com/katex/-/katex-0.16.3.tgz#29640560b8fa0403e45f3aa20da5fdbb6d2b83a8" integrity sha512-3EykQddareoRmbtNiNEDgl3IGjryyrp2eg/25fHDEnlHymIDi33bptkMv6K4EOC2LZCybLW/ZkEo6Le+EM9pmA== </del> <ins> version "0.16.4" resolved "https://registry.yarnpkg.com/katex/-/katex-0.16.4.tgz#87021bc3bbd80586ef715aeb476794cba6a49ad4" integrity sha512-WudRKUj8yyBeVDI4aYMNxhx5Vhh2PjpzQw1GRu/LVGqL4m1AxwD1GcUp0IMbdJaf5zsjtj8ghP0DOQRYhroNkw== </ins> dependencies: commander "^8.0.0"

Related discussion:
text: <!-- 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.62.2 OS Version: Windows 8.1 Steps to Reproduce: a markdown file with the following content: Open a Preview to the side Rendering/Parsing of line 5 goes wrong Parsing of line 6 gives the: I have line 3 and 4 to determine what causes the problem, it is the literal text at the end of line 5: Any literal text (single backtick) of the content: generates the error If there is a tag on a line, any literal text (single backtick) after that is not recognized by the syntax highlighting in the editor
I have just updated the extension that has this piece of Markdown in the README. Github, Marketplace and Extension Bar all render the markdown correct.
I recommend that you disable the built-in , because it turns the Markdown inside VS Code to a flavor much different from GFM that you apparently don't want. The Markdown Math was introduced in . Besides, if you install some VS Code extensions that offer math support someday, you will need to check their documentation to disable the corresponding features. The rendering did not go wrong, to my knowledge. You just discovered the dark side of Markdown. Markdown is not a single rigorous language, but a collection of various flavors (aka "dialect", "variant") that disagree with each other. Let's take a glance at its history first, though there should already be more detailed articles on the Internet. created in 2004. It's the origin of Markdown, and unfortunately ambiguous. Soon, flavors bloomed.
Code change:
integrity sha512-OkTL9umf+He2DZkUq8f8J9of7yL6RJKI24dVITBmNfZBmri9zYZQrKkuXiKhyfPSu8tUhnVBB1iKXevvnlR4Ww== katex@^0.16.2: <del> version "0.16.3" resolved "https://registry.yarnpkg.com/katex/-/katex-0.16.3.tgz#29640560b8fa0403e45f3aa20da5fdbb6d2b83a8" integrity sha512-3EykQddareoRmbtNiNEDgl3IGjryyrp2eg/25fHDEnlHymIDi33bptkMv6K4EOC2LZCybLW/ZkEo6Le+EM9pmA== </del> <ins> version "0.16.4" resolved "https://registry.yarnpkg.com/katex/-/katex-0.16.4.tgz#87021bc3bbd80586ef715aeb476794cba6a49ad4" integrity sha512-WudRKUj8yyBeVDI4aYMNxhx5Vhh2PjpzQw1GRu/LVGqL4m1AxwD1GcUp0IMbdJaf5zsjtj8ghP0DOQRYhroNkw== </ins> dependencies: commander "^8.0.0"

Related discussion:
text: Many years later, a group led by began to develop . The new spec has become the basis of many flavors in recent years. Among these derivatives, the current , , is the one that you're familiar with. Interestingly, a number of Markdown implementations adopt GFM and modify its extensions to create new flavors, for example, . I don't know the very flavor that VS Code's Markdown Math tries to follow, but it ( and . Please correct me. Now we can see that lots of Markdown flavors are technically incompatible. Thus, it's a pity that Markdown users have to configure their processors to get desired results. Here, in VS Code, the built-in ships a GFM-like environment. You can to get a more GFM-like experience as long as you're careful.
Minimal example that demonstrates the issue:
Marking as a good first issue since this should be a fairly scoped bug Here's the relevant repository where this issue should be fixed: The repo includes tests that you can use to confirm the issue is fixed and also check for regressions
I am looking to fix this by not allowing a dangling dollar symbol inside a markdown block to open or close. Do you think I'm on the right path?
I still do not regard the behavior here as a bug. Things just work this way as per the inline parsing strategy of CommonMark. From a CommonMark-compliant parser's view, we can say in a non-normative way that is equivalent to Then, given the enabled rules ( default, CommonMark HTML, pandoc-style math, and something else), it's recognized as This is correct and exactly reflects the philosophy of CommonMark. This issue ought to be marked as flavors are not compatible, . A derivative flavor can inherit the philosophy of its parent, but cannot retain the semantics. In other words, you cannot enable a math plugin and expect GFM-like rendering at the same time. You can only discuss right or wrong within the same flavor. If you want GFM-like rendering, disable the built-in Markdown Math () extension first.
But how do I write in Markdown Math a line that shows me Is there a way to Escape the
Avoid plain HTML-like pieces in Markdown. Use proper syntax whenever possible. In Markdown, HTML-like pieces (leaf block "HTML block" and inline structure "Raw HTML") are nothing, but just a kind of literal content.
Code change:
integrity sha512-OkTL9umf+He2DZkUq8f8J9of7yL6RJKI24dVITBmNfZBmri9zYZQrKkuXiKhyfPSu8tUhnVBB1iKXevvnlR4Ww== katex@^0.16.2: <del> version "0.16.3" resolved "https://registry.yarnpkg.com/katex/-/katex-0.16.3.tgz#29640560b8fa0403e45f3aa20da5fdbb6d2b83a8" integrity sha512-3EykQddareoRmbtNiNEDgl3IGjryyrp2eg/25fHDEnlHymIDi33bptkMv6K4EOC2LZCybLW/ZkEo6Le+EM9pmA== </del> <ins> version "0.16.4" resolved "https://registry.yarnpkg.com/katex/-/katex-0.16.4.tgz#87021bc3bbd80586ef715aeb476794cba6a49ad4" integrity sha512-WudRKUj8yyBeVDI4aYMNxhx5Vhh2PjpzQw1GRu/LVGqL4m1AxwD1GcUp0IMbdJaf5zsjtj8ghP0DOQRYhroNkw== </ins> dependencies: commander "^8.0.0"

Related discussion:
text: CommonMark requires implementations to skip them: There are roughly 7 + 6 rules for recognizing HTML-like pieces; HTML-like pieces are captured, and then emitted as-is to the output, without further touching parser's machine state. This design is a compromise for compatibility, and causes usability and security issues, like your cases. jgm complained about the terrible fact many years ago. As for escaping, if your use case is presenting a character in textual content, you can try "backslash escape" like , and "entity and character reference" like and .
Maybe the wrong example asked, the OP was about some italic (or bold) text inside a code block, it was done with <codefoo<embar</emfoo</codeand when you use a character outside backticks and further down on the line a it goes wrong. I did not know Markdown allowed HTML entities. I have now enabled Markdown Math and replaced all characters inside with and now there is no
Excuse me? I'm confused now. So, you add these dangerous pieces to your Markdown document for formatting? Unfortunately, CommonMark Markdown is not a superset of WHATWG HTML. They actually have almost no intersection, and apply nearly opposite handling when encountering pieces that look like HTML tags. If you decide to have HTML-like things in a Markdown document, you have to be careful, and know how to lead the parser to your desired result. I thought I've made these basic facts clear. But seems no. No one understands my comments above. Before I come up with another way to explain, we can demonstrate something by this sample: If it's treated as HTML, there is one element with a comment and a text node "" inside. However, if you feed it to a CommonMark-compliant renderer, you'll get somewhat illegal HTML output:
If they are so dangerous why do they allow HTML tags in CommonMark Markdown? As soon as you use single or triple backtick all inside is treated as literal, there is AFAIK no way to make something inside italic (or bold) using Markdown syntax. I use HTML tags to get the required rendered output.
Good to know. Then, you only need to be careful when configuring Markdown renderer and authoring Markdown documents. This is for not only performance but also conformance. Avoid using inappropriate parsers, as flavors may hold dramatically different logic.
Code change:
integrity sha512-OkTL9umf+He2DZkUq8f8J9of7yL6RJKI24dVITBmNfZBmri9zYZQrKkuXiKhyfPSu8tUhnVBB1iKXevvnlR4Ww== katex@^0.16.2: <del> version "0.16.3" resolved "https://registry.yarnpkg.com/katex/-/katex-0.16.3.tgz#29640560b8fa0403e45f3aa20da5fdbb6d2b83a8" integrity sha512-3EykQddareoRmbtNiNEDgl3IGjryyrp2eg/25fHDEnlHymIDi33bptkMv6K4EOC2LZCybLW/ZkEo6Le+EM9pmA== </del> <ins> version "0.16.4" resolved "https://registry.yarnpkg.com/katex/-/katex-0.16.4.tgz#87021bc3bbd80586ef715aeb476794cba6a49ad4" integrity sha512-WudRKUj8yyBeVDI4aYMNxhx5Vhh2PjpzQw1GRu/LVGqL4m1AxwD1GcUp0IMbdJaf5zsjtj8ghP0DOQRYhroNkw== </ins> dependencies: commander "^8.0.0"

Related discussion:
text: For example, , , and can give mostly different results for the same input. The Markdown flavor of GitHub is GFM. GitHub processes user content with , and then pipes the HTML output through some "filters" to add GitHub-specific features, such as sanitization, heading anchors, emoji codes, issue references, and diagrams. , VS Code's provides default + , which is a few steps away from GitHub. Basically, you just need to install extensions for emoji and task list, and disable those that don't exist on GitHub (e.g. ). Additionally, since VS Code and GitHub generate heading ID with slightly different methods, a link to heading might work on one and break on the other. It's John Gruber, , that introduced "HTML" (but not real HTML). The world has no choice but to live with it. If you ask me to judge Gruber's decision, I'd say the "HTML" in Markdown is a sign of laziness, besides, thousands of collective developer hours have been wasted due to tons of lazy and ambiguous design of the original Markdown. He should have defined generic construct syntax first, and built language structures on top of it. Probably I'm bad at teaching. But other people have good skill in communication. I recommend their articles:
Code change:
# Copyright (c) Microsoft Corporation. All rights reserved. # Licensed under the MIT License. See License.txt in the project root for license information. <del> rm -f /usr/bin/@@NAME@@ </del>  No newline at end of file <ins> rm -f /usr/bin/@@NAME@@ # Update mimetype database for removed workspace mimetype if hash update-mime-database 2>/dev/null; then update-mime-database /usr/share/mime fi </ins>

Related discussion:
text: A Visual Studio Code workspace file is currently recognised in Linux as a normal plain text file. This is because there isn't a MIME type for this file. Applications can provide additional MIME types as described here: Not having a MIME type has a couple of issues, for example the files are shown as plain text files in the GUI, which makes it hard to distinguish source code files from the workspace file. This slows down navigating to a workspace and opening it. Find the workspace in the following screenshot ! It's currently impossible to theme such a file because it's not seen as a different MIME type:
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.461 --<!-- potentialduplicatescomment --
This also means that you can't make double clicking the workspace from a file browser open it in vscode, unless you're OK with all text files opening in vscode, which is probably not what most folks want.
This bug has been fixed in to the latest release of ! you can help us out by confirming things are working as expected in the latest Insiders release. If things look good, please leave a comment with the text to let us know. If not, please ensure you're on version of Insiders (today's or later - you can use in the command pallete to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Hi can you verify this issue? Check out the previous comment.
I tried to verify this but am not sure how to do this myself. I've not used desktop linux extensively; I tried reinstalling Insiders from the on Lubuntu to see if it associated files with VS Code, but that didn't happen.
Verified by installing insiders from on Ubuntu and was able to see mimetype and set a custom icon ! upon uninstalling it was removed.
Code change:
ca2186313d3cbe5c67d0c08e931a6d290906f4f13c584e63fefa05a04dee9c58  node-v18.15.0-linux-armv7l.tar.gz b298a73a9fc07badfa9e4a2e86ed48824fc9201327cdc43e3f3f58b273c535e7  node-v18.15.0-linux-x64.tar.gz 17fd75d8a41bf9b4c475143e19ff2808afa7a92f7502ede731537d9da674d5e8  win-x64/node.exe <del> d78b2f981465a40a23b964b2db32a390db1970a0dd5371682e121ae2b7422697  win-x86/node.exe </del>

Related discussion:
text: Type: <bBug</bThis issue is related to the Julia extension. I filed an issue , but I also filing it here (as suggested by As per the initial post of the above link, all extension work perfectly fine when the Julia extension is disabled. here are dmp files as per VS Code version: Code 1.79.2 (, 2023-06-14T08:57:04.379Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryExtensions (50)</summaryExtensionVersion ------ rainbow-brackets0.0.6 vscode-django1.10.0 python-environment-manager1.0.4 python-extension-pack1.7.0 code-runner0.12.0 copilot1.94.220 vscode-github-actions0.25.8 vscode-pull-request-github0.66.2 nbpreviewer1.2.2 language-julia1.47.2 vsc-python-indent1.18.0 vscode-github0.30.7 vscode-opn1.1.2 MagicPython1.1.0 vscode-azureappservice0.24.9 vscode-azureresourcegroups0.7.5 vscode-docker1.25.2 csharp1.26.0 isort2022.8.0 python2023.10.1 vscode-pylance2023.6.40 jupyter2023.5.
Code change:
ca2186313d3cbe5c67d0c08e931a6d290906f4f13c584e63fefa05a04dee9c58  node-v18.15.0-linux-armv7l.tar.gz b298a73a9fc07badfa9e4a2e86ed48824fc9201327cdc43e3f3f58b273c535e7  node-v18.15.0-linux-x64.tar.gz 17fd75d8a41bf9b4c475143e19ff2808afa7a92f7502ede731537d9da674d5e8  win-x64/node.exe <del> d78b2f981465a40a23b964b2db32a390db1970a0dd5371682e121ae2b7422697  win-x86/node.exe </del>

Related discussion:
text: jupyter-keymap1.1.2 jupyter-renderers1.0.15 vscode-jupyter-cell-tags0.1.8 vscode-jupyter-slideshow0.1.5 remote-containers0.295.0 remote-ssh0.102.0 remote-ssh-edit0.86.0 remote-wsl0.79.5 vscode-remote-extensionpack0.24.0 azure-account0.11.5 cmake-tools1.14.34 cpptools1.16.3 cpptools-extension-pack1.3.0 powershell2023.6.0 remote-explorer0.4.0 remote-server1.2.1 autodocstring0.6.1 r-debugger0.5.4 r2.8.1 vscode-open0.1.0 spellchecker1.4.0 python0.2.3 rmarkdown0.0.14 cmake0.0.17 vscode-counter3.2.1 intellicode-api-usage-examples0.2.7 vscodeintellicode1.2.30 jinja0.0.8 (2 theme extensions excluded) </details<details<summaryA/B Experiments</summary</details<!-- generated by issue reporter --
As mentioned in the linked issue, it happens for me as well. I can reproduce it with Insiders version too and the same happens with a few older julia-vscode extensions I tested. <details<summaryVS Code version</summary</details
There seems to be an issue with spawning a process. The symbolicated logs seem to have the same form.
I'd expect that this happens when we try to spawn the Julia process that powers the LS. Any chance we can debug this further? I assume we can't handle libuv failing to spawn a process anywhere in the extension code, right?
As asked in the I want to add that I can reproduce this as well. From the linked thread:
Sorry for the delayed response, can you please provide the output of the following steps to understand the error 1) In a terminal set the following env variable 2) Launch VSCode from the same terminal session with arguments that redirect stdout and stderr to a file as seen below, replace the file paths where appropriate Additionally, once the extension host crashes open command palette in VSCode and run and attach the output from the tab of the developer tools that got opened.
Code change:
ca2186313d3cbe5c67d0c08e931a6d290906f4f13c584e63fefa05a04dee9c58  node-v18.15.0-linux-armv7l.tar.gz b298a73a9fc07badfa9e4a2e86ed48824fc9201327cdc43e3f3f58b273c535e7  node-v18.15.0-linux-x64.tar.gz 17fd75d8a41bf9b4c475143e19ff2808afa7a92f7502ede731537d9da674d5e8  win-x64/node.exe <del> d78b2f981465a40a23b964b2db32a390db1970a0dd5371682e121ae2b7422697  win-x86/node.exe </del>

Related discussion:
text: unfortunately this is a fatal error that cannot be handled in the application layer. But we should be able to see the output of from the above logs.
I have done this, see attached.
Same here
Thanks for the logs, in both cases the launching of child process triggers a fatal error from at due to . I would like to understand if this can repro with outside VSCode since we haven't done any modification to the spawn API. I have simplified the Julia language server process spawn call from your logs into the following script, can you run it with node v18.15.0 which can be downloaded from , the steps would be 1) Save the following script to 2) Install v18.15.0 3) From terminal, run and attach the generated output
Apparrently Julia expects 8 arguments. Not sure why though.... if length(Base.ARGS) != 8 error("Invalid number of arguments passed to julia language server.") end
can you help with above error, I would like to create a minimal repro outside VSCode since this is an issue with
It seems we need additional arguments in in the .js file see or here
I two empty arguments in the file However, I have no idea if these arguments are relevant. Then things seem to work Are we expecting the server to shut down at the end? EDIT: the process only shuts down if I hit enter. If I don't press any key it keeps running and the last message is 'Received new data from Julia Symbol Server..." output is:
Thanks for fixing the test case No, I was expecting the error to show up
Can you run our bisect tool in the terminal . In each step install the Julia extension (if not present) and if the extension host terminates with the above error, mark it as bad commit. This would help us narrow down if a change from our side introduced the regression.
Looking at the above, the argument right after is In the test case, I set this argument to empty though
I think it is fine to skip the pipe name, looking at the code it is only responsible for monitory crashes from the language server.