mirror of
https://github.com/yuin/goldmark
synced 2025-03-04 23:04:52 +00:00
7cdc0fb06f
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 . |
||
|---|---|---|
| .. | ||
| attribute.go | ||
| atx_heading.go | ||
| auto_link.go | ||
| blockquote.go | ||
| code_block.go | ||
| code_span.go | ||
| delimiter.go | ||
| emphasis.go | ||
| fcode_block.go | ||
| html_block.go | ||
| link.go | ||
| link_ref.go | ||
| list.go | ||
| list_item.go | ||
| paragraph.go | ||
| parser.go | ||
| raw_html.go | ||
| setext_headings.go | ||
| thematic_break.go | ||