关闭 BND 仓库问题列表。
给某些人解释事情是真费劲，我想过上彪悍的人生。
少即是多。
如果需要解决鸡蛋问题，那说明正在干的事情有点价值。
开始实现 Lute source map（源码映射）：实现源码位置（source position）解析映射，可用于判断某个字符位置所在 AST 节点，以支持编辑器场景实现光标位置描述。Issue #26 · b3log/lute
Source Map 即 Markdown 源码和 HTML 目标代码之间的字符关联信息。要实现双向映射 AST 上必须要有结构来存储映射关系：
其实不用源码映射也可以实现上述功能，只是在稍微复杂的 Markdown 源码中会出现小问题。能结构化解决的问题最好结构化解决，否则应用陷入 if else 的泥潭就惨了。
Vditor 中加入了 Markdown AST 可视化功能，这样大大方便了后续开发调试。
其实应该早点写这个工具的，之前调试起来真的是惨无人道 🤣
工欲善其事必先利其器
Markdown 源码位置映射很麻烦啊，只有很少数的 Markdown 引擎进行了实现。
Issue #29 · commonmark/commonmark.js
Google AdSense 账号再次因为无效流量被限制投放了，有人利用 https://www.googleapis.com/auth/chrome-content-suggestions 作为 Referer 头进行恶意点击。感觉是 Google AdSense 对这个头开了白名单，导致无效流量清洗不到位。
https://www.googleapis.com/auth/chrome-content-suggestions
突然反思一个问题，所见即所得的 Markdown 编辑器真的好么？这似乎违背了 Markdown 设计的初衷：通过简单标记排版从而“所见即所得”。
换个角度，所见即所得的 Markdown 也许是在富文本编辑器和分屏预览 Markdown 之间的一个折中。分屏预览虽然不错，但是如果标记过多（特别是链接、图片）容易干扰视觉从而影响行文思路。所见即所得的 Markdown 解决了这个问题并且获得了富文本编辑器的一些特性，最重要的是保持了 Markdown 排版方式。这样的设计也许就是“刚刚好”的设计。
不管了不管了，好用才是最终评判标准。
重新实现了 Lute 的 Markdown 格式化功能（Markdown to AST to Markdown formatted）。再写个 HTML Parser 就可以完成 HTML to Markdown 了（HTML to AST to Markdown formatted）。
解析器和渲染器完全分离的设计开始发挥作用了。
有的时候我感觉自己像个怨妇，但我明明想做一个泼妇。
放弃 TinyGo Wasm 方案，改用 GopherJS 方案，一下子简单很多，包也小，非常完美 🤣
TinyGo 探坑终于见底了，还剩两个标准库函数实现完了就可以用了。
Lute 的 TinyGo 编译 Wasm 还是报错。
panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0xb53f4e] goroutine 1 [running]: github.com/tinygo-org/tinygo/vendor/golang.org/x/tools/go/ssa.(*Type).Type(...) /root/go/src/github.com/tinygo-org/tinygo/vendor/golang.org/x/tools/go/ssa/ssa.go:1465
Lute 已经可以通过 Wasm 来支持 JavaScript 调用了，继续优化包大小。
GitHub 把 B3log 的账号封禁了，等下发工单问下原因。
无论现在是否离开，都需要做好随时离开的准备。
Lute M1 完成了，准备开始 M2。
Lute 基本稳定了，继续优化性能。
社区的 Markdown 引擎已经切换为 Lute 了，这标志着 Vditor 里程碑 1 已经达成，Vditor 的下一个里程碑是实现所见即所得。
下一代的 Markdown 编辑器，为未来而构建
开始给 Lute 加入中文语境优化，比如中英文字符间插入空格、链接识别加强等。参考文献：
关闭 BND 仓库问题列表。
给某些人解释事情是真费劲，我想过上彪悍的人生。
少即是多。
如果需要解决鸡蛋问题，那说明正在干的事情有点价值。
开始实现 Lute source map（源码映射）：实现源码位置（source position）解析映射，可用于判断某个字符位置所在 AST 节点，以支持编辑器场景实现光标位置描述。Issue #26 · b3log/lute
什么是 Source Map
Source Map 即 Markdown 源码和 HTML 目标代码之间的字符关联信息。要实现双向映射 AST 上必须要有结构来存储映射关系：
Source Map 有什么用
其实不用源码映射也可以实现上述功能，只是在稍微复杂的 Markdown 源码中会出现小问题。能结构化解决的问题最好结构化解决，否则应用陷入 if else 的泥潭就惨了。
Vditor 中加入了 Markdown AST 可视化功能，这样大大方便了后续开发调试。
其实应该早点写这个工具的，之前调试起来真的是惨无人道 🤣
Markdown 源码位置映射很麻烦啊，只有很少数的 Markdown 引擎进行了实现。
Issue #29 · commonmark/commonmark.js
Google AdSense 账号再次因为无效流量被限制投放了，有人利用
https://www.googleapis.com/auth/chrome-content-suggestions作为 Referer 头进行恶意点击。感觉是 Google AdSense 对这个头开了白名单，导致无效流量清洗不到位。突然反思一个问题，所见即所得的 Markdown 编辑器真的好么？这似乎违背了 Markdown 设计的初衷：通过简单标记排版从而“所见即所得”。
换个角度，所见即所得的 Markdown 也许是在富文本编辑器和分屏预览 Markdown 之间的一个折中。分屏预览虽然不错，但是如果标记过多（特别是链接、图片）容易干扰视觉从而影响行文思路。所见即所得的 Markdown 解决了这个问题并且获得了富文本编辑器的一些特性，最重要的是保持了 Markdown 排版方式。这样的设计也许就是“刚刚好”的设计。
不管了不管了，好用才是最终评判标准。
重新实现了 Lute 的 Markdown 格式化功能（Markdown to AST to Markdown formatted）。再写个 HTML Parser 就可以完成 HTML to Markdown 了（HTML to AST to Markdown formatted）。
解析器和渲染器完全分离的设计开始发挥作用了。
有的时候我感觉自己像个怨妇，但我明明想做一个泼妇。
放弃 TinyGo Wasm 方案，改用 GopherJS 方案，一下子简单很多，包也小，非常完美 🤣
TinyGo 探坑终于见底了，还剩两个标准库函数实现完了就可以用了。
Lute 的 TinyGo 编译 Wasm 还是报错。
Lute 已经可以通过 Wasm 来支持 JavaScript 调用了，继续优化包大小。
GitHub 把 B3log 的账号封禁了，等下发工单问下原因。
Lute M1 完成了，准备开始 M2。
Lute 基本稳定了，继续优化性能。
社区的 Markdown 引擎已经切换为 Lute 了，这标志着 Vditor 里程碑 1 已经达成，Vditor 的下一个里程碑是实现所见即所得。
开始给 Lute 加入中文语境优化，比如中英文字符间插入空格、链接识别加强等。参考文献：