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

Improve heading syntax region #604

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

amarakon
Copy link
Contributor

Markdown headings have at least one whitespace character after the hashtag(s).

This is a heading

#This is not a heading

@alerque
Copy link
Member

alerque commented Sep 30, 2022

This is an interesting one and I'm not 100% sure what to do. This rule is implemented differently across different Markdown parsers. The original daring fireball "spec" wasn't clear, and bath ways started getting implemented early on. These days many of the more formalized specs such as CommonMark, Pandoc FM, GitHub FM, etc. have converged on requiring the space. Many older or less spec dependent parsers don't care. Others like it-markdown have extensions to make them optional.

This raises the issue (yet again) of what this plugin targets. This is very much a legacy project and I think it should probably default to targeting as generic and legacy a "flavor" as possible. There are other plugins for Pandoc specific syntax or CM or whatever.

However given the daring fireball examples use a space (even if it wasn't required) I wonder how many people's usage this would actually break and whether the extra reliability and fewer false positives might be worth it anyway.

Thoughts?

@tomtomjhj
Copy link
Contributor

See also: #598

@amarakon
Copy link
Contributor Author

This is an interesting one and I'm not 100% sure what to do. This rule is implemented differently across different Markdown parsers. The original daring fireball "spec" wasn't clear, and bath ways started getting implemented early on. These days many of the more formalized specs such as CommonMark, Pandoc FM, GitHub FM, etc. have converged on requiring the space. Many older or less spec dependent parsers don't care. Others like it-markdown have extensions to make them optional.

This raises the issue (yet again) of what this plugin targets. This is very much a legacy project and I think it should probably default to targeting as generic and legacy a "flavor" as possible. There are other plugins for Pandoc specific syntax or CM or whatever.

However given the daring fireball examples use a space (even if it wasn't required) I wonder how many people's usage this would actually break and whether the extra reliability and fewer false positives might be worth it anyway.

Thoughts?

I think we should add the space by default, then add an option to remove the space. Also, in Pandoc Markdown, #. can be used for ordered lists. This creates a false positive.

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

Successfully merging this pull request may close these issues.

None yet

3 participants