go-term-markdown
go-term-markdown copied to clipboard
parser choke on CR LF (windows) endline
create a new md example file.
$ cat example.md
**strftime日期和时间格式说明符**
| 格式 | 描述 |
| ---- | ---- |
| %a | 星期几的缩写(Sun) |
| %A | 星期几的完整写法(Sunday) |
| %b | 月名的缩写(Oct) |
| %B | 月名的完整写法(October) |
| %c | 本地日期和时间 |
| %d | 十进制日期 |
| %D | 日期 08/20/99 |
| %e | 日期,如果只有一位会补上一个空格 |
| %H | 用十进制表示24小时格式的小时 |
| %I | 用十进制表示12小时格式的小时 |
| %j | 从1月1日起一年中的第几天 |
| %m | 十进制表示的月份 |
| %M | 十进制表示的分钟 |
| %p | 12小时表示法(AM/PM) |
| %S | 十进制表示的秒 |
| %U | 十进制表示的一年中的第几个星期(星期天作为一个星期的开始) |
| %w | 十进制表示的星期几(星期天是0) |
| %W | 十进制表示的一年中的第几个星期(星期一作为一个星期的开始) |
| %x | 重新设置本地日期(08/20/99) |
| %X | 重新设置本地时间(12:00:00) |
| %y | 两位数字表示的年(99) |
| %Y | 当前月份 |
| %% | 百分号(%) |
exec mdr command, as you can show below, it can't render the right format.
$ mdr example.md
strftime日期和时间格式说明符 | 格式 | 描述 | | ---- | ---- | | %a | 星期几的缩写(Sun) | | %A | 星期几的完整写
法(Sunday) | | %b | 月名的缩写(Oct) | | %B | 月名的完整写法(October) | | %c | 本地日期和时间 | | %d | 十进制日
期 | | %D | 日期 08/20/99 | | %e | 日期,如果只有一位会补上一个空格 | | %H | 用十进制表示24小时格式的小时 | |
%I | 用十进制表示12小时格式的小时 | | %j | 从1月1日起一年中的第几天 | | %m | 十进制表示的月份 | | %M | 十进制表
示的分钟 | | %p | 12小时表示法(AM/PM) | | %S | 十进制表示的秒 | | %U | 十进制表示的一年中的第几个星期(星期天作
为一个星期的开始) | | %w | 十进制表示的星期几(星期天是0) | | %W | 十进制表示的一年中的第几个星期(星期一作为一个
星期的开始) | | %x | 重新设置本地日期(08/20/99) | | %X | 重新设置本地时间(12:00:00) | | %y | 两位数字表示的年
(99) | | %Y | 当前月份 | | %% | 百分号(%) |
It renders properly for me, same with mdr
:
Maybe try another terminal ?
It did render properly in my both environment below:
Raspbian 8 Jessie, ARM v6l, Bash 4.3.30, MDR v0.2.1
![スクリーンショット 2020-01-04 0 30 17](https://user-images.githubusercontent.com/11840938/71732113-d0668b80-2e89-11ea-9c9a-59ce2309e7dc.png)
macOS Mojave 10.14.5, Intel x86_64, Bash 3.2.57, MDR v0.2.1
![スクリーンショット 2020-01-04 0 28 33](https://user-images.githubusercontent.com/11840938/71732099-c5136000-2e89-11ea-88eb-89b2593ad365.png)
Maybe Windows' CRLF thing?
It's strange, how about this? @MichaelMure
table still can not show properly
$ wget https://raw.githubusercontent.com/jaywcjlove/linux-command/master/command/awk.md
$ mdr awk.md
my os is macos and terminal is iterm2.
Yeah, it's the endlines, if you convert your file it render nicely.
endlines? Could you show me how to do it? :)
A lot of editors have an option to convert the endlines between windows and unix. Otherwise you can do something like this: https://stackoverflow.com/a/2613834
So the bug is not actually in this package, but in gomarkdown: https://github.com/gomarkdown/markdown/issues/137
I suppose go-term-markdown
could enforce the unix endlines before throwing the input at gomarkdown
but that's kinda silly.
I convert newline in code. kinda silly, but works.
content := make([]byte, 0)
reader := bufio.NewReader(resp.Body)
for {
line, _, err := reader.ReadLine()
if err != nil && err != io.EOF {
return err, 0
}
if err == io.EOF {
break
}
content = append(content, line...)
content = append(content, []byte("\n")...)
}
Now I'm curious what would be the most efficient way to fix those newline between your solution, the one in the linked issue with bytes.Replace
(see below), strings.ReplaceAll
or strings.Replacer
(see https://stackoverflow.com/a/52600147). Some benchmarking is needed.
// NormalizeNewlines normalizes \r\n (windows) and \r (mac) // into \n (unix)
func NormalizeNewlines(d []byte) []byte {
// replace CR LF \r\n (windows) with LF \n (unix)
d = bytes.Replace(d, []byte{13, 10}, []byte{10}, -1)
// replace CF \r (mac) with LF \n (unix)
d = bytes.Replace(d, []byte{13}, []byte{10}, -1)
return d
}