Note that this is a breaking change and will require new goldmark major version.
I have tried to fix problem with leading tabs in fenced code blocks (and probably normal code blocks too).
Important note - tabs do not behave like "just 4 spaces". They "finish" 4 space columns. So tab can behave like anything between 1 space to 4 spaces, depending on position.
If you have MD like this (. represents space, [tb] , [t] or [] tabs)
```
*.some.text
..```
..foo
..[]foo
..```
```
you expect the tab to be kept in the code. This did not work properly in goldmark and I fixed that.
However, if you have a code like this
```
*.some.text
..```
..foo
.[t]foo
..```
```
what should happen? I decided that it should be two spaces, as the tab is not "completely" in the code block. Similarly, what should happen in this case
```
*.some.text
..```
..foo
.[t][tb]foo
..```
```
I decided that it should be first three spaces and then tab. Not sure what even is the correct solution here...
The crux of the fix is - text segments don't have just padding, but also remember what chars is the padding and then print that, if they are called to do so in the code blocks. In other cases, the paddingChars are ignored.
This should fix#177 .
This makes three changes to backlinks:
- Inserts a space before `<a href='…'>↩</a>` to make it look better
- Uses hexadecimal references (`&#x…;`) instead of decimal references for clarity
- Adds U+FE0E VARIATION SELECTOR 15 to the ↩ to suppress emojification on both iOS and Edge on Windows
If variation selector 15 isn't appended to the ↩, then the return arrow will show up as an emoji on iOS and Edge for Windows. The Pandoc project has already run into this quirk as documented on https://github.com/jgm/pandoc/issues/5469 and they've pushed a change for their Markdown processor already.