There isn't really a reason why markdown in issues, Pull requests and discussions can't be GFM. Almost every markdown render engine can do at least the basic render of whatever comes between the open and close of the block and the more sophisticated ones support specifying a language variant immediately after the opening blocks. I think this is the most flexible (should support a wide number of future usecases!) and also the most backwards compatible. Off of the top of my head, these plugins: The obsidian community has (at least partially) settled on triple backticks for this. It precisely prevents the need to increment syntax.īeta Was this translation helpful? Give feedback. I don’t see the need for parity, which is indeed impossible, when there is a syntax for these custom things. Given that there are already some solution out there, would we ever reach a point of parity or would we just increase the Markdown rendering clutter I envision that unknown directives can be either: a) displayed somewhat similar to how YAML frontmatter is displayed, so that their name and attributes are displayed, b) replaced with their contents, similar to how unknown HTML tags are stripped Once they would support the concept of generic directives it still requires to adopt the exact pattern and render it accordingly to achieve the same meaning. And I prefer going with standards, and as far as I know generic directives are supported in many places already and most likely to become that.
I see a need for an arbitrary “component” syntax, to quell the ever growing need to add things. That is why, while I quite like the Obsidian syntax, and also quite like the current proposal, keeping on adding things just makes markdown like AsciiDoc, and AsciiDoc is already the best AsciiDoc out there.
And humans will have other custom needs for their markdown too. This is not the first nor the last feature GitHub adds. The inverse is also true: the things GitHub implements, are “forced” upon other markdown parsers due to the sheer popularity of GitHub. Markdown files are rendered with different Markdown parsers outside of GitHub that won't support that syntax to begin with Which is all the more reason to do it properly, ask the community for feedback ( 👍), and work with existing proposals. GitHub, by introducing a syntax, will change some readmes. Noteworthy, this has not prevented a) GitHub rebasing GFM on top of CommonMark, b) the recent additions of diagrams, footnotes, and math. Github uses Liguist to perform language detection and syntax highlighting, so the above may not be needed after all.I'm wondering how everyone feels about the fact that it would potentially break backwards compatibilityĪny change to markdown introduces those: as any character is valid markdown, turning them into constructs is breaking.
My ( $self, $paragraph ) = analyze $paragraph and return language identifier To expand on this logic, or to add other languages one may subclass this module and overwrite the syntax method. This module performs a very simple linguistic check to identify if it's dealing with Perl code. This module inherits from Pod::Markdown and adds those backticks and an optional language identifier. Github flavored markdown allows for syntax highlighting using three backticks. Version 0.04 SYNOPSIS perl -MPod::Markdown::Github -e "Pod::Markdown::Github->filter('file.pod')" DESCRIPTION Pod::Markdown::Github - Convert POD to Github's specific markdown VERSION
0 kommentar(er)
