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

Fix no-break space on lists #1398

Closed
wants to merge 1 commit into from

Conversation

mccraveiro
Copy link
Contributor

Marked version: master branch

Markdown flavor: CommonMark

Description

Important: This PR introduces parsing of invisible unicode characters. Please double check it!

Input

* a *

Important: note that is not a normal space. It is a "no-break unicode space"

Expectation

<p>* a *</p>

Result

<ul>
<li>a *</li>
</ul>

What was attempted

Stops replacing "no-break" spaces and fixes the example with the correct unicode char

Contributor

  • Test(s) exist to ensure functionality and minimize regression (if no tests added, list tests covering this PR); or,
  • no tests required for this PR.
  • If submitting new feature, it has been documented in the appropriate places.

Important: I had to change 2 old tests so they match the spec. Please double check it! :)

Committer

In most cases, this should be a different person than the contributor.

  • Draft GitHub release notes have been updated.
  • CI is green (no forced merge required).
  • Merge PR

@UziTech
Copy link
Member

UziTech commented Dec 20, 2018

I think we want to keep replacing \u00a0 with a regular space by default. see #52 and #897

I think the conclusion to #897 was to create an option to keep \u00a0

@mccraveiro
Copy link
Contributor Author

@UziTech that would mean marked would never be 100% CommonMark compliant. Are we fine with that?

@UziTech
Copy link
Member

UziTech commented Dec 20, 2018

I'm ok with it not being 100% compliant by default as long as there are options that will make it 100% compliant.

@styfle
Copy link
Member

styfle commented Dec 20, 2018

I think when #897 was created, I didn't realize that it was in favor of the commonmark spec rather than a personal preference.

We are in a bit of a pickle 🥒

  • we don't like breaking backwards compatibility
  • we don't like deviating from Commonmark spec
  • we don't like adding new options

So which is the greater of the evils? 😈

/cc @joshbruce @davisjam

@UziTech
Copy link
Member

UziTech commented Dec 21, 2018

I can't find the discussion but I think the original idea was to limit the number of breaking changes and when we get to v1.0 deprecate a bunch of things and remove things in v2.0

After looking at https://libraries.io/npm/marked/usage it looks like most dependents are pinned to pre v0.4 anyways so breaking changes shouldn't be as big of an issue as previously suspected.

@UziTech UziTech mentioned this pull request Apr 19, 2019
5 tasks
@UziTech UziTech mentioned this pull request Aug 5, 2019
4 tasks
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