-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include Github Flavored Markdown(GFM) in core as an option #164
Comments
Bumping @pdeschen @SyntaxRules |
I think Adding in the GFM features is smart, and an easy way to compete with other parser's out there. Marked does this via on option, but i would discourage putting it as an option in Showdown. The advantage Showdown has over Marked is that it is easily extendable. I think all of these quirky features should got in a GFM plugin. This plugin could depend upon other plugins. This way someone could pick and choose which items they want in there markdown. If we feel strongly about including GFM features, we could include them by default. |
Github Flavored Markdown detects urls and mails embeded in the text without any extra markup or delimiter. This commit adds this feature to showdown through an option called "simplifiedAutoLink". Related to #164
@SyntaxRules Yeah, I agree. The only thing is that some features have to be included directly in core, since they would need to be run in a specific order, something that showdown extensions don't support. |
…underscores Github Flavored Markdown does not parse underscores in the middle of a word as emphasis/bold. This commit adds this feature to showdown through an option called "literalMidWordUnderscores". Related to #164
Github Flavored Markdown supports strikethrough (`<del>`) syntax using double tilde `~~` delimiters. This commit adds this feature to showdown through an option called "strikethrough". Related to #164
Github Flavored Markdown supports a specific table syntax. Table support was already available as an extension. With this commit, the feature was moved to core, adding this feature to showdown through an option called "tables". Related to #164
Github Flavored Markdown supports tasklist by `[x]` or `[ ]` after list item marker. This commit adds this feature to showdown through an option called "tasklists". Related to #164
A bit confused by this, I see in the documentation on the front page it mentions that |
In short:
Showdown supports them if you activate them via options. Else, you get vanilla markdown. Give it a try.
Where in the wiki? Please add a link so we can update to make things a bit more clear. This issue might confuse people since it refers to "plugins" which isn't accurate. Extra markdown features are implemented in separate subParsers. This means they can easily be turned on/off at will. That's what SyntaxRules was talking about. |
https://github.com/showdownjs/showdown/wiki/extensions That lists the extensions for table etc. I did try to use the options and they didnt seem to change anything.
Then if I were to add
as shown in the example, it does not get processed, it just outputs it within a |
Are you using version 1.2.0 ? Enviado do meu iPhone No dia 20/07/2015, às 16:22, LP [email protected] escreveu:
|
Sorry for the afk-ness, no I am on 1.1.0, but I only got that like a week or so ago, has it already changed so much? will go get latest and see what happens. |
I'm actually for both options, but if have to choose only one then probably the first. |
Introduction
Showdown tries to follow vanilla markdown (with all its quirks and perks) as much as possible but several related issues (see #96, #152, for instance) were raised requesting showdown to fully support GFM.
(See GFM differences from traditional Markdown here).
Some features of GFM are already available from within showdown:
~~word~~
) is available as an extension: (github-extension)However, other features require changing showdown's core parsers:
<http://www.example.com>
autolink style. GFM autolinkshttp://www.example.com
(no need to wrap in <>). A output extension might be able to take care of this, but the regex used would have to be complex to properly parse edge cases (for instance, a link inside a code block, or in a src attribute, etc...)Options
We have 2 options to deal with these requests:
and the third option... use both.
Thoughts?
The text was updated successfully, but these errors were encountered: