search

facelessuser / sublime-markdown-popups

Markdown popup dependency for Sublime
https://facelessuser.github.io/sublime-markdown-popups/
Other
112 stars 13 forks source link

Fix Markdown issues in TSDoc #134

Closed tukusejssirs closed 2 years ago

tukusejssirs commented 2 years ago

Related: #103, sindresorhus/execa#507

I presume that all these issues would be fixed by moving to CommonMark (see #103)

I wanted to fix this in sindresorhus/execa#507, but the owner is not really interested in working around sublime-markdown-popups limitations. CommonMark is what [he is] used to and prefer.

Issues:

facelessuser commented 2 years ago

We will probably never move fully to Commonmark, but the plan is to make it an option if/when Package Control ever supports Python 3.8. I have no plan to backport any new modules back to the ancient Python 3.3, so we need Python 3.8 dependency support first.

MdPopups was never meant to parse any Markdown from any parser. It was simply meant to be a way to create popups from user-crafted Markdown, not arbitrary Markdown from any location.

With that said, LSP has been heavily utilizing mdpopups, and it is, at times, literally parsing Markdown from arbitrary, unknown locations.

I cannot guarantee that the Commonmark parser we select in the future will be 100% compatible with every other Commonmark parser (though it should when dealing with basic, standard Markdown - or at least that is the intention), but it will hopefully be more reliable in the future.

Keep in mind, if/when this happens, I will not specifically be addressing issues with whatever parser we select, those would be upstream issues with the parser we've chosen. My support will be limited to any extensions we must provide to allow for basic usage in Sublime Text. For instance, we may have to provide an extension to ensure we can syntax highlight code for Sublime Text within the Commonmark parser we chose.

As for this point:

SMP requires specification of syntax highlighting language for code blocks, otherwise entire code block is in a single colour, while VSCode infers the language somehow.

I don't recall if we expose language guessing. Since the idea was users crafting their Markdown content, we required them to specify the language. Personally, I don't think Pygment's (the syntax library under the hood) always gets guessing right, so I don't often use it. This may be the only issue that could warrant its own issue. If this is important, please create a separate, specific issue, and I may look into exposing such an option.

Anyways, as I already have an open issue (#103) to add CommonMark, I will close this issue as I will not specifically be looking into SMP issues, and I will not be altering Python Markdown to accommodate such issues as these are likely issue integral to the Python Markdown parser and how it works.