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

A few fixes to inline styles and code blocks #69

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

lilyball
Copy link

This contains various fixes, including:

  • Inline styles shouldn't work across blank lines.
  • Inline styles shouldn't highlight if the close token isn't present.
  • [link text][destination] blocks should allow a newline where currently only a single space is allowed.
  • Fenced code blocks can start after blockquotes, like other block-level elements.
  • Blockquotes shouldn't require the space.
  • More flexible fenced code block start/end tokens.

I think this at least partially obsoletes #16.

Inline styles, such as emphasis, code, and links, cannot contain an
empty line. Change the definitions so they won't ever try to match
across an empty line, and in fact won't even start the match unless
there's a valid end.
When detecting whether an inline span applies, consider a line that only
contains a blockquote start indicator to be blank.
A newline (followed by any number of spaces) is always allowed between a
[link text] and a [link destination] block, even in the original
Markdown. Various implementations allow it between [link text] and
(inline url) blocks as well.
Add fenced code blocks to @markdownBlock, so they can start inside a
blockquote.
Even the original Markdown doesn't require the space here.
Fenced code blocks can use either ``` or ~~~ as a delimiter, and can
include more than 3 backticks/tildes in a row if they want (~~~~). It
also appears that the start and end markers don't have to match.

This was verified in both the redcloth Markdown implementation and
GitHub-Flavored Markdown.
@MarkLodato
Copy link

Friendly ping. Any chance this can be pulled in? There are a lot of good fixes in here. Thanks!

@tpope
Copy link
Owner

tpope commented Sep 25, 2015

Have you been using them for a while? This is a tremendous amount to audit.

@MarkLodato
Copy link

I've been using this for about a year now and consider them critical, particularly "Allow newline after [link text] block" and "Treat fenced code blocks like other block-level elements". The "Don't match inline spans..." and "Better fenced code block matching" are also nice but I only hit them every so often. I never used blockquotes so I haven't tested "Consider lines with..." and "Don't require a space...".

@tpope
Copy link
Owner

tpope commented Sep 25, 2015

The inline styles stuff is most worrying to me; the current balance is quite precarious. I will try it locally. You can check back in in a couple of weeks or so.

@lilyball
Copy link
Author

I've also been using this ever since I submitted it. Admittedly I don't edit markdown in Vim particularly often, but I haven't had any problems.

@MarkLodato
Copy link

@tpope Would it help to break up this PR into smaller ones that could be reviewed independently? If so, would you be willing to do that, @lilyball?

@tpope
Copy link
Owner

tpope commented Sep 19, 2021

Having back-burnered this for 7 years, what I need first is someone to investigate and summarize which fixes are still relevant to master, and which aren't.

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.

3 participants