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 .
Remove buf, which appears to be created and appended to but never used
for anything. Found with staticcheck check SA4010 ("The result of
append will never be observed anywhere").
godoc.org is deprecated and will begin redirecting to pkg.go.dev in
early 2021. Update link and badge to point to pkg.go.dev
See https://blog.golang.org/godoc.org-redirect for more information.
According to the GFM spec (and per other implementations), a space
should be inserted after the checkbox input element. This gives visual
separation between the checkbox and its element. Update code and tests
to match.
Signed-off-by: Alexander Scheel <alexander.m.scheel@gmail.com>
