Skip to content
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

Request: ability to turn off Setext-style headers and non-fenced code blocks #49

Open
iosdev-republicofapps opened this issue Jan 28, 2015 · 4 comments

Comments

@iosdev-republicofapps
Copy link

Hi,

Would you be open having two options added to MMarkdownExtensions:

  1. MMMarkdownExtensionsNoSetextHeaders: Disable detection of headers like
A Setext Header
=============

and instead only allow the

# Atx Style Headers
  1. MMMarkdownExtensionsNoSpaceIndentedCodeBlocks: Disable detection of code blocks preceded by four spaces as in:
    This would no longer be a code block.

and instead allow fenced code blocks (if MMMarkdownExtensionsFencedCodeBlocks is enabled).

I ask because I'm making a user-facing Markdown app and I want to avoid confusion amongst my users about whether to use the # (Atx) or === (Setext) headers. I also want to avoid confusion about space-indented code blocks.

Also, turning off Setext headers and space-indented code blocks makes Markdown syntax highlighting within the markdown input editor much easier.

I think this would be two simple changes in MMMarkdown.h and MMParser.m.

If I was willing to make these code changes, including automated tests, on a fork, would you be open to a pull request to merge this into the master branch? :-)

I'm really enjoying MMMarkdown (thanks!) and I need these two new flags but I'd rather avoid forking and diverging my own version from your master since that will make subsequent updates to your later releases more difficult and require git merges, etc.

In my experience, use of Setext headers is rare since they only have 2 levels of headers (compared to 6 for Atx). Also, fenced code blocks seem far more popular than space-indented ones in my experience.

Thanks and best wishes.

@mdiep
Copy link
Owner

mdiep commented Jan 29, 2015

I'm going to take a couple days to think about it, but I think I'm probably okay with doing this.

@iosdev-republicofapps
Copy link
Author

Awesome, thanks! :-)

@mdiep
Copy link
Owner

mdiep commented Jan 30, 2015

I'm okay with this approach if you want to open a PR. ☺️

@iosdev-republicofapps
Copy link
Author

Thanks! Will do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants