Tencent
引入Milkdown实现所见即所得编辑模式
Clear and concise description of the problem or idea.
https://github.com/Milkdown/milkdown 本来想基于ProseMirror手撸所见即所得（类typro）编辑模式，结果发现了milkdown，交互体验不错，于是决定直接引入milkdown来实现该功能。
实现后CherryMarkdown将具备三种模式：
- 双栏编辑模式（可以关闭预览）
- 纯预览模式（包括针对流式会话的流式会话模式）
- 所见即所得WYSIWYG模式（类typro）
由于所见即所得模式是通过milkdown实现的，所以这里会不可避免地出现语法兼容、交互体验不统一、主题样式冲突等问题，这需要比较长期的优化。
当然目前还是个想法，如果遇到其他更优的组件也会考虑更换（不过目前体验的组件里，milkdown交互体验是最好的一个）
milkdown的中间玩了两天， 我的方案是只在render侧实现了cherry的特殊语法，用户在文本修改的时候，还是会按照milkdown的语法编辑， 但是milkdown开发起来真的烦， 因为本身是基于ProseMirror的，总是要考虑cursor，position，selection这些， 简单插件还好， 写复杂插件的时候，debug的时候特别烦躁，也可能是因为我的Prosemirro用的不好导致的。不过它的table选中和复合元素选中总是有问题， 我也一直没调好，后面我干脆不干了
milkdown的中间玩了两天， 我的方案是只在render侧实现了cherry的特殊语法，用户在文本修改的时候，还是会按照milkdown的语法编辑， 但是milkdown开发起来真的烦， 因为本身是基于ProseMirror的，总是要考虑cursor，position，selection这些， 简单插件还好， 写复杂插件的时候，debug的时候特别烦躁，也可能是因为我的Prosemirro用的不好导致的。不过它的table选中和复合元素选中总是有问题， 我也一直没调好，后面我干脆不干了
厉害~ 我也听说prosemirror的学习曲线比较陡，我们选择milkdown主要是从交互体验上来考虑的，milkdown的交互体验还是非常流畅自然的。。。
我个人理解，如果是想做协作相关的文档工具，Prosemirro是个不错的选择，因为它能控制的粒度足够精细，但是如果不涉及协作的话，真不建议用Prosemirro来做编辑器，太啰嗦，而且还很难用好，特别在团队共同维护的时候，一个不够好的插件，可以直接让整个编辑器崩溃，
我个人理解，如果是想做协作相关的文档工具，Prosemirro是个不错的选择，因为它能控制的粒度足够精细，但是如果不涉及协作的话，真不建议用Prosemirro来做编辑器，太啰嗦，而且还很难用好，特别在团队共同维护的时候，一个不够好的插件，可以直接让整个编辑器崩溃，
额，确实，prosemirror的学习曲线比较陡，不过不得不承认prosemirror本身还是非常优秀的（包括性能、扩展性、社区），所以我们还是想试试基于prosemirror的milkdown。。。
我个人理解，如果是想做协作相关的文档工具，Prosemirro是个不错的选择，因为它能控制的粒度足够精细，但是如果不涉及协作的话，真不建议用Prosemirro来做编辑器，太啰嗦，而且还很难用好，特别在团队共同维护的时候，一个不够好的插件，可以直接让整个编辑器崩溃，
额，确实，prosemirror的学习曲线比较陡，不过不得不承认prosemirror本身还是非常优秀的（包括性能、扩展性、社区），所以我们还是想试试基于prosemirror的milkdown。。。
那你们开始了吗？我没看到对应的分支
那你们开始了吗？我没看到对应的分支
在搞了（进度0）。。。最近新增的issue比较多，有些是用户真实场景遇到的，需要我们高优先级去实现。。。所以这个需求就被一直往后拖。。
