你快回家吧……
它的源码模式是基于 CodeMirror 做的，CodeMirror 用的是正则，不专业
一样不解析嘛
Vditor 是严格遵循 Markdown 标准的，所以这些细节也扣的比较死
但是，空列表项解析
空标题不解析的
这是 Markdown 语法规定的
所以手机上编辑帖子时，界面也是相当奇怪
这个问题 V 尝试搞过，没搞定
是的
Vditor 等我们再优化下，还需要你来帮忙测试用户体验
这估计得 APP 才行
丢失焦点？
从前面提到的实现方式上来说，vditor、typora、mt 这三者一样，都是靠堆代码量解决场景的
marktext 做了 diff 但是还有些小问题，vditor 也有类似问题
typora 的代码上次我看了一些，它好像没做 diff，是全局解析的
类似的场景还有一个是链接引用
性能好的不一定对，你可以试下 footnotes 改引用和定义部分，看看能不能联动
还有一点……性能不是首要考虑的，首要考虑的是实现应用场景的正确性
diff tree 的好处就是不用管语法细节，简单粗暴，但是优化效果没法做到最优，还是靠特定场景优化才能得到最优解。
这个方案上有的项目是通过 diff tree 来做，那个性能我测过更差，所以没考虑，现在是自己实现的算法，基于 Markdown 特性来做的，比如在操作 list 的时候可能会涉及到的影响，在操作 footnotes 时可能会涉及到的影响，把影响单独拉出来，然后单独解析 DOM 生成 Markdown AST 进行渲染
这个过程的优化就是局部渲染，只对部分 DOM 进行自旋，减少 DOM 解析渲染工作量。
就是把用户操作的 DOM 转换成新 DOM
这个过程 Vditor 里面叫做“自旋”
比如 Vditor 的话，局部渲染指的主要是我们自己实现的 DOM to Markdown 再 to DOM 这个过程
渲染这个词分为好几层
浏览器的渲染就是可视区域渲染
VNote 我不确定没看过，但我觉得应该是。
几乎主流平台编程语言都自带类似 webview 的控件
你快回家吧……
它的源码模式是基于 CodeMirror 做的，CodeMirror 用的是正则，不专业
一样不解析嘛
Vditor 是严格遵循 Markdown 标准的，所以这些细节也扣的比较死
但是，空列表项解析
空标题不解析的
这是 Markdown 语法规定的
所以手机上编辑帖子时，界面也是相当奇怪
这个问题 V 尝试搞过，没搞定
是的
Vditor 等我们再优化下，还需要你来帮忙测试用户体验
这估计得 APP 才行
丢失焦点？
从前面提到的实现方式上来说，vditor、typora、mt 这三者一样，都是靠堆代码量解决场景的
marktext 做了 diff 但是还有些小问题，vditor 也有类似问题
typora 的代码上次我看了一些，它好像没做 diff，是全局解析的
类似的场景还有一个是链接引用
性能好的不一定对，你可以试下 footnotes 改引用和定义部分，看看能不能联动
还有一点……性能不是首要考虑的，首要考虑的是实现应用场景的正确性
diff tree 的好处就是不用管语法细节，简单粗暴，但是优化效果没法做到最优，还是靠特定场景优化才能得到最优解。
这个方案上有的项目是通过 diff tree 来做，那个性能我测过更差，所以没考虑，现在是自己实现的算法，基于 Markdown 特性来做的，比如在操作 list 的时候可能会涉及到的影响，在操作 footnotes 时可能会涉及到的影响，把影响单独拉出来，然后单独解析 DOM 生成 Markdown AST 进行渲染
这个过程的优化就是局部渲染，只对部分 DOM 进行自旋，减少 DOM 解析渲染工作量。
就是把用户操作的 DOM 转换成新 DOM
这个过程 Vditor 里面叫做“自旋”
比如 Vditor 的话，局部渲染指的主要是我们自己实现的 DOM to Markdown 再 to DOM 这个过程
渲染这个词分为好几层
浏览器的渲染就是可视区域渲染
VNote 我不确定没看过，但我觉得应该是。
几乎主流平台编程语言都自带类似 webview 的控件