Lute 要做到极致的性能，必须去掉词法分析。词法分析的作用是把输入文本的字符分类形成 token，这就需要完整遍历一遍输入文本。这个遍历过程虽然比较快，但是构造 token 对象却是很耗时的（规范文本有 12W+ 个 tokens ）。所以如果要做到极致的性能，必须把词法分析过程省掉，在语法分析阶段根据字符值操作。这样减少了遍历次数，也减少了内存分配和 GC。
Lute 通过了全部的 CommonMark 测试用例 🎉
Lute 测试用例进度 625/649。不出意外的话明天就可以完成了，然后花一周左右时间进行重构和性能调优。
Lute 测试用例进度 549/649。还差 100 个就通关 CommonMark 了，下一个目标是实现一些 GFM 的扩展语法支持。
开始为 Symphony 社区系统投放 Google Ads 广告。
看到著名 Markdown 程序员 phodal 被骂（两年前的事情）
没有干货代码最好不要营销，不然会被骂惨的。
所有 HTML 实体的 JSON 结构化数据：https://html.spec.whatwg.org/entities.json
虽然已经理解了 CommonMark 规范文末提到的解析算法，但自己独立进行实现还真搞不定。在抄了官方参考实现项目 commonmark.js 部分代码后，Lute 块级元素解析基本重写完毕。
参考实现就是用来参考的。况且，读书人的事情怎么能叫偷？
当然这是开玩笑的。Lute 鸣谢部分见，感谢开源 ❤️
妖精，快还我爷爷！
if grandparent := node.Parent().Parent(); nil != grandparent && NodeList == grandparent.Type() { if grandparent.(*List).tight { return WalkContinue, nil } }
该吹的都已经吹出去了，接下来就看能实现到那种程度了。能做好就是真牛，做不好就是吹牛。
CommonMark 没有二义性。
我应该早点把黑客派的流量统计从百度统计换成谷歌分析的，谷歌分析的用户体验真的很棒！
昨晚写完了 Lute 的块级元素解析，并通过了测试用例 296。但是代码实现结构性太差，别人读起来肯定很困难，也不利于以后维护，今早决定推翻重写。
之前是完全使用递归下降写的，生成 AST 时不需要遍历，最多只需要回退两行源文本。但这个实现方式在处理块级容器（列表、列表项、块引用）时异常艰难，所以决定还是按照 CommonMark 规范里面介绍的解析策略进行吧，每次读取新行后遍历已有树，在未关闭的节点上做判断操作。这样做虽然每次解析新行时都要遍历树，但是实现起来会容易很多，另外考虑到 Markdown 的 AST 不会出现太多层级，其实遍历树也不会太耗时间的。
唉，不听老人言，吃亏在眼前啊 😂
Lute 测试用例进度 243/649。
BND 上 GitHub 热榜了：
不要忽略任何一个细节，特别是被命名为类似 chunk 的东西。
Lute 进展到了块引用的细节处理，真心佩服 jgm。
Lute 测试用例进度 145/649。
今天 Lute 通过了 1/6 的 CommonMark 测试用例，争取这个月通关。
要是所有事情都得给别人解释，那哪来时间写代码。
Lute 要做到极致的性能，必须去掉词法分析。词法分析的作用是把输入文本的字符分类形成 token，这就需要完整遍历一遍输入文本。这个遍历过程虽然比较快，但是构造 token 对象却是很耗时的（规范文本有 12W+ 个 tokens ）。所以如果要做到极致的性能，必须把词法分析过程省掉，在语法分析阶段根据字符值操作。这样减少了遍历次数，也减少了内存分配和 GC。
Lute 通过了全部的 CommonMark 测试用例 🎉
Lute 测试用例进度 625/649。不出意外的话明天就可以完成了，然后花一周左右时间进行重构和性能调优。
Lute 测试用例进度 549/649。还差 100 个就通关 CommonMark 了，下一个目标是实现一些 GFM 的扩展语法支持。
开始为 Symphony 社区系统投放 Google Ads 广告。
看到著名 Markdown 程序员 phodal 被骂（两年前的事情）
没有干货代码最好不要营销，不然会被骂惨的。
所有 HTML 实体的 JSON 结构化数据：https://html.spec.whatwg.org/entities.json
虽然已经理解了 CommonMark 规范文末提到的解析算法，但自己独立进行实现还真搞不定。在抄了官方参考实现项目 commonmark.js 部分代码后，Lute 块级元素解析基本重写完毕。
当然这是开玩笑的。Lute 鸣谢部分见，感谢开源 ❤️
妖精，快还我爷爷！
该吹的都已经吹出去了，接下来就看能实现到那种程度了。能做好就是真牛，做不好就是吹牛。
CommonMark 没有二义性。
我应该早点把黑客派的流量统计从百度统计换成谷歌分析的，谷歌分析的用户体验真的很棒！
昨晚写完了 Lute 的块级元素解析，并通过了测试用例 296。但是代码实现结构性太差，别人读起来肯定很困难，也不利于以后维护，今早决定推翻重写。
之前是完全使用递归下降写的，生成 AST 时不需要遍历，最多只需要回退两行源文本。但这个实现方式在处理块级容器（列表、列表项、块引用）时异常艰难，所以决定还是按照 CommonMark 规范里面介绍的解析策略进行吧，每次读取新行后遍历已有树，在未关闭的节点上做判断操作。这样做虽然每次解析新行时都要遍历树，但是实现起来会容易很多，另外考虑到 Markdown 的 AST 不会出现太多层级，其实遍历树也不会太耗时间的。
唉，不听老人言，吃亏在眼前啊 😂
Lute 测试用例进度 243/649。
BND 上 GitHub 热榜了：
不要忽略任何一个细节，特别是被命名为类似 chunk 的东西。
Lute 进展到了块引用的细节处理，真心佩服 jgm。
Lute 测试用例进度 145/649。
今天 Lute 通过了 1/6 的 CommonMark 测试用例，争取这个月通关。
要是所有事情都得给别人解释，那哪来时间写代码。