求关于 Markdown 或类似标记语言的任何吐槽、建议、个人使用风格说明。

[jakwings]

对回复者的第一条回复必送感谢！
最好让这个主题成为 Markdown 节点的吐槽集中营，好方便其它想实现类似 Markdown 的标记语言的设计者参考。

[SoloCompany]

@jakwings thanks, 怎么我看过的文档似乎都没提到过这种用法呢
另外我测试了下
`<http://foo.com>`
或者
<`http://foo.com`>
都没法实现 URL 的格式化

如果用 wiki markup
{{[http://foo.com]}}
就可以了

这个真心的觉得不如 wiki 方便

[jakwings]

@SoloCompany 你是要纯文本还是自动添加链接的 URL ？若是要链接，去掉左引号。自动链接是 Markdown 原生支持的语法。
Wiki 用的语法其实是方便 wiki 的各个页面之间的联系而设计的，不会简单到哪里去的。不过 Wiki 系统都挺适合写博的，因为可以轻松地手动联系自己的各篇文章。

自动用 <br> 换行的功能我已经在自己设计中的语言的转换工具实现了。其实段落 <p> 才是正确的分行方式，行距可以用 CSS 修改的，实在是不明白为什么对紧凑的内容这么喜爱呢。

[SoloCompany]

@jakwings 我是想添加URL并且用等宽显示，md 好像不会自动添加链接啊，所以才很纠结

换行和分段的问题这个显然是md设计失误，我觉得wiki markup合理的多，换行自动保留，如果连续超过两个换行就分段

[jakwings]

@SoloCompany URL 本来就可能够长了，还用等宽字体……的确要重复写链接了，不过用链接 ID 来引用看起来会比较干净。

换行我不认为是 md 的设计失误，只能说是一种风格吧，因为 Markdown 是支持 Lazy Syntax 的，作者也是个喜欢邮件使用固定宽度内容的人，比较偏向英文使用者。只能怪当时作者没考虑过非拼音语言使用者的感受吧。

[hzlzh]

你要找的是不是这个：1MarkDown - 团队统一书写规范，我之前写过。
https://github.com/hzlzh/1MarkDown

[darkbill]

@strak47 如果是要居中的话，写一段latex语句放在preamble中就可以了。
举例如下：
\titleformat{\section}{}{\thesection}{}{%
\centering\Huge\bfseries
}[] %这是居中显示标题，用Huge级别的字号，以及粗体显示。

如果使用pandoc的话，把上面的话存成一个文件header.latex，在格式转换的时候 pandoc -H header.latex <正文文件> 即可。

[jakwings]

@hzlzh 不是的。另外，那份文档挺多关于空白行分隔的说明似乎描述和示例不完全符合，我看了源文件了。

[SoloCompany]

回去看了下文档，貌似 <> 是给 email 嵌入用的，还真没想到过也可以用来嵌入 URL
这个还真是有点绕，为什么不直接支持 (url) 或者 [url] 或者 [](url) 呢
非得逼着人写 [url](url)
虽然我已经慢慢习惯用 id 引用了，但即使有了 id 引用也无法实现简单的 URL 嵌入需求

[jakwings]

@SoloCompany ()是常用来附加说明文本的，不应该单独成为标记，[](url) 可能意味着不包括链接文本，没用 [url] 而是 <url> ，我也不知道为什么。
<> 的官方说明在这里：http://daringfireball.net/projects/markdown/syntax/#autolink

[yukirock]

@jakwings

> 其实让 text-indent 影响图片没什么不好，因为假如文本不是溢出分出多行的话，图片处于段落边界之外还是挺难看的，又得特地给图片加缩进等级。

我不太了解你描述的是什么样式，如果可以的话，方便举例吗？

p>img 的问题在于，图片的左边界是与首行缩进齐平，换言之如果正常布局的话，左边的边距会大于右边。即使是居中放置也是如此。

分段的两种方法，其一缩进，其二增加段间距，的确如果用后一种的话就没有这个问题，但这并没有解决问题。相反，从语法上避免生成 p>img，我认为是更好的做法。

再细分下来的话，即使是图片也有两种类型。其一是大片的插图，其二是行间图片，如图片格式的颜文字或字库中没有、需要用图片呈现的字符。现有的标记语言对后者可以轻松加愉快的搞定，而前者从逻辑上并不是段落的一部分，也不应当独占一个段落。

> 用标记符号的长度来指示层级，其实在视觉上并不明显，内容多了便看不清楚了。另外也一般来说也不必太多缩进层级吧？缩进三层最少用 6 个空格便可以了。

我一直认为把缩进作为语法是不恰当的，且不说 tab 和空格的选择，对于可以处理格式的编辑器来说，缩进的逻辑结构非常不稳定。或者说前面标记层级的字符至少不应该用 \s。

而这个和缩进多少层级并没有多少联系。如果一个系统设计得很糟糕，它有可能在情况简单时坏掉，也的确有更大的可能在复杂的情况下坏掉。但是「因为在简单的情况下不容易坏所以无所谓」的话，我认为这是在隐瞒问题。

[jakwings]

@yukirock
> p>img 的问题在于，图片的左边界是与首行缩进齐平，换言之如果正常布局的话，左边的边距会大于右边。即使是居中放置也是如此。

我之前试过了，图片这种 inline-block 元素竟然没有应用文字的 text-indent ，直接靠左对齐了。而为图片应用 display:block 和 margin:auto 进行居中时，也会忽略 text-indent 。所以假如要左对齐的话，若要配合行首缩进，还得添加 CSS 为图片进行缩进。

我也为我的 Strictdown 语言添加了表示单独的图片的语法了。行内图片的确还是挺有用的。

> 我一直认为把缩进作为语法是不恰当的，且不说 tab 和空格的选择，对于可以处理格式的编辑器来说，缩进的逻辑结构非常不稳定。或者说前面标记层级的字符至少不应该用 \s。

其实我干脆支持用空格而不是 tab ，因为 tab 的呈现在各种编辑器上不确定。用空格缩进的话，可能真的不太适合制作自动格式化辅助工具，不过我认为应该先把可读性问题解决，一般情况下缩进也不需要缩进多少个字符。

缩进层级增加会增加哪方面的不稳定性呢？而且在深度缩进时有没有在折腾一般人不会添加的复杂内容？
而缩进导致的内容边界问题，可以用一个简单的分界标记来解决，而且这种情况也不会很常见。

[jakwings]

@yukirock 啊，貌似我之前的测试结果有点问题。重新测试了一下： http://jsfiddle.net/y9nfP/
结果是 text-indent 只影响不居中的图片。

[yukirock]

> 我之前试过了，图片这种 inline-block 元素竟然没有应用文字的 text-indent ，直接靠左对齐了。而为图片应用 display:block 和 margin:auto 进行居中时，也会忽略 text-indent 。所以假如要左对齐的话，若要配合行首缩进，还得添加 CSS 为图片进行缩进。

http://jsfiddle.net/yukirock/RSH2d/1/

> 缩进层级增加会增加哪方面的不稳定性呢？而且在深度缩进时有没有在折腾一般人不会添加的复杂内容？

自动处理缩进的编辑器（如 vim 的 =）会无从区分行首的 \s 到底是语法还是单纯的格式。如果误用这些自动工具的话很容易把排好的缩进打乱。我的意见是，不管用什么符号，要能和惯用的缩进符号区分开来，不致引起歧义。

再者「一般人不会添加的复杂内容」，不正是开发者应当考虑的方面嘛。

[jakwings]

@yukirock 不知道 52 楼你有没有看到。

之所以会说添加复杂内容，我设计的 Strictdown 语言是支持的：
https://github.com/jakwings/strictdown
不过编辑器插件要不要完全迁就就要看实用性质了，添加复杂内容本来就已经快要超出这类语言的极限了。

你说的歧义问题，只是和编辑器的格式化功能或者代码高亮功能有关的。

自动缩进功能其实真的不需要太精确，缩进不对了，手动敲几个空格就能矫正了。代码高亮插件也可以稍微降低一下精度，不会严重影响视觉效果。像 Vim 这种纯文本编辑工具要实现自动格式化编辑还是比较难的，用网页在线编辑器会更容易实现（例如通过特殊按键组合退出当前编辑的文本块）。