[GH-ISSUE #367] MD020: Breaking &nbps; not detected inbetween heading hashtags and heading title #2156

New issue

Closed

opened 2026-03-07 20:05:06 +03:00 by kerem · 2 comments

kerem commented

2026-03-07 20:05:06 +03:00

Owner

Originally created by @muttoni on GitHub (Jan 19, 2021).
Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/367

Hi, I had a devilishly difficult to track markdown issue caused by a weird space character inbetween the heading hashtags and the heading title. This was all due to the decimal charcode being 160 (non breaking space  ) instead of 32 (a regular space).

---

## Subheading that doesn't work

## Subheading that works
---

## Subheading that doesn't work

Subheading that works

Could you please detect this as an issue? As you can see, it breaks the Github markdown parser as well and it's very hard to track down unless you know the issue. I was blaming the surrounding contents for breaking the parser as Markdown Lint does not flag this as an issue (see below).

Edit: I initially thought this could be a rare edge case, but I've now realized what caused the nbps...typing with an IT layout means that in order to type a hashtag I need to press the Alt Gr modifier key (+ à). The modifier key also causes spacebar to generate a non-breaking space. When typing quickly it's easy to press spacebar while Alt Gr is still pressed.

Originally created by @muttoni on GitHub (Jan 19, 2021). Original GitHub issue: https://github.com/DavidAnson/markdownlint/issues/367 Hi, I had a devilishly difficult to track markdown issue caused by a weird space character inbetween the heading hashtags and the heading title. This was all due to the decimal charcode being 160 (non breaking space ` `) instead of 32 (a regular space). ``` --- ## Subheading that doesn't work ## Subheading that works --- ``` --- ## Subheading that doesn't work ## Subheading that works --- Could you please detect this as an issue? As you can see, it breaks the Github markdown parser as well and it's very hard to track down unless you know the issue. I was blaming the surrounding contents for breaking the parser as Markdown Lint does not flag this as an issue (see below). ![image](https://user-images.githubusercontent.com/27052451/105038939-3e173280-5a60-11eb-9fd4-bf3230d43557.png) **Edit**: I initially thought this could be a rare edge case, but I've now realized what caused the nbps...typing with an IT layout means that in order to type a hashtag I need to press the <kbd>Alt Gr</kbd> modifier key (+ <kbd>à</kbd>). The modifier key also causes <kbd>spacebar</kbd> to generate a non-breaking space. When typing quickly it's easy to press <kbd>spacebar</kbd> while <kbd>Alt Gr</kbd> is still pressed.

kerem

2026-03-07 20:05:06 +03:00

closed this issue
added the
bug

fixed in next
labels

kerem commented

2026-03-07 20:05:07 +03:00

Author

Owner

@muttoni commented on GitHub (Jan 19, 2021):

Upon browsing the source code, this is likely falls in the MD020 category. It also might be a good time to extend the test across all types of non-admissable whitespace characters:

U+0009 Horizontal tab (HT)
U+00A0 Non-break space
U+1680 Ogham space mark
U+180E Mongolian vowel separator
U+2000 En quad
U+2001 Em quad
U+2002 En space
U+2003 Em space
U+2004 Three-per-em space
U+2005 Four-per-em space
U+2006 Six-per-em space
U+2007 Figure space
U+2008 Punctuation space
U+2009 Thin space
U+200A Hair space
U+202F Narrow no-break space
U+205F Medium mathematical space
U+3000 Ideographic space

@muttoni commented on GitHub (Jan 19, 2021): Upon browsing the source code, this is likely falls in the **MD020** category. It also might be a good time to extend the test across all types of non-admissable whitespace characters: ``` U+0009 Horizontal tab (HT) U+00A0 Non-break space U+1680 Ogham space mark U+180E Mongolian vowel separator U+2000 En quad U+2001 Em quad U+2002 En space U+2003 Em space U+2004 Three-per-em space U+2005 Four-per-em space U+2006 Six-per-em space U+2007 Figure space U+2008 Punctuation space U+2009 Thin space U+200A Hair space U+202F Narrow no-break space U+205F Medium mathematical space U+3000 Ideographic space ```

kerem commented

2026-03-07 20:05:07 +03:00

Author

Owner

@DavidAnson commented on GitHub (Jan 19, 2021):

This looks to be because the CommonMark definition of "whitespace" is more restrictive than JavaScript's RegExp:

@DavidAnson commented on GitHub (Jan 19, 2021): This looks to be because the CommonMark definition of "whitespace" is more restrictive than JavaScript's RegExp: - https://spec.commonmark.org/0.29/#characters-and-lines - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions/Character_Classes